Homebrew to menedżer pakietów dla macOS używany przez miliony deweloperów. Instaluje się jednym poleceniem wklejanym do terminala. To polecenie wygląda tak:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"30 kwietnia 2026 roku Bradley Duncan z SANS Internet Storm Center odkrył że pierwszy wynik Google dla frazy "Homebrew" prowadził do fałszywej strony hostowanej na Google Sites. Strona była wizualnie identyczna z oficjalną. Polecenie instalacyjne wyglądało niemal identycznie. Zamiast Homebrew instalowało MacSync Stealer.
Atak nie wymagał żadnej podatności w Homebrew. Nie wymagał włamania na żadne serwery. Wymagał tylko kupienia reklamy w Google — co jest dostępne dla każdego z kartą płatniczą.
Dlaczego curl | sh jest zarówno standardem jak i problemem
Żeby zrozumieć dlaczego ta klasa ataków jest trudna do zatrzymania szkoleniami, trzeba zrozumieć jak deweloperzy macOS instalują oprogramowanie.
curl | sh — pobranie skryptu z internetu i bezpośrednie przekazanie go do powłoki systemowej — to wzorzec instalacyjny używany przez Homebrew, Rust (cargo), nvm, wielu innych popularnych narzędzi. Jest powszechny dlatego że jest wygodny: jedno polecenie, bez pobierania pliku, bez oddzielnego uruchamiania instalatora.
Michael Bell z Suzu Labs ujmuje problem precyzyjnie: "Nie możemy mówić pracownikom technicznym 'nigdy nie wklejaj poleceń', kiedy tak właśnie działa połowa ich zestawu narzędzi."
Atakujący to wiedzą. Kampania MacSync jest zaprojektowana dokładnie wokół tego: wygląda jak normalna instalacja, zachowuje się jak normalna instalacja, aż do momentu gdy złośliwy kod zaczyna zbierać dane. Użytkownik wkleił polecenie, terminal poprosił o hasło (jak zawsze przy instalacji), i tyle — interakcja wygląda identycznie jak przy legalnym Homebrew.
Co MacSync zbiera
MacSync Stealer to rozbudowany zbieracz danych wycelowany w środowiska deweloperskie. Docelowe kategorie danych są dokładnie te same które opisywaliśmy przy Shai-Hulud i kampaniach TeamPCP: pliki .aws i .kube z poświadczeniami chmurowych, historia powłoki systemowej, dane z przeglądarek (ciasteczka, hasła, rozszerzenia), macOS Keychain z hasłami systemowymi, dane z portfeli kryptowalutowych.
Szczegół z analizy Daylight Security: MacSync szuka aktywnych sesji Kubernetes i konfiguracji AWS — nie tylko kluczy dostępowych, ale aktywnych tokenów sesji które dają natychmiastowy dostęp bez potrzeby uwierzytelnienia. Ten sam typ danych który był celem w ataku przez LMDeploy i LiteLLM.
Dane są kompresowane do /tmp/osalogging.zip i wysyłane na serwer sterujący. Cały łańcuch wykonuje się w pamięci — brak plików pośrednich zapisywanych na dysku, co utrudnia wykrycie przez klasyczne skanery.
Infrastruktura na Google Sites — zaufana platforma jako hosting złośliwej strony
Jest jeden szczegół tej kampanii który wyróżnia ją spośród standardowego malvertisingu: strona podszywająca się pod Homebrew była hostowana na sites.google.com/view/brewpage — oficjalnej platformie Google Sites.
To ten sam mechanizm który opisywaliśmy przy Shai-Hulud używającym Hugging Face jako infrastruktury dostarczania ładunków i kampaniach TeamPCP przez Docker Hub. Zaufane platformy mają z definicji czystą reputację domeny — filtry sieciowe organizacji domyślnie przepuszczają ruch do google.com, github.com, huggingface.co. Atakujący nie muszą budować własnej infrastruktury z dobrą reputacją — wystarczy że skorzystają z istniejącej.
Mike McQuaid, lider projektu Homebrew, skomentował publicznie z widoczną frustracją: "There's little we can do about this really, it keeps happening again and again and Google seems to like taking money from scammers." To nie jest pierwsza kampania malvertisingu celująca w Homebrew — identyczny wzorzec pojawił się w 2025 roku i wcześniej.
Ten sam wzorzec co CPUID, inny kanał
Przy ataku na CPUID pisaliśmy że atakujący nie złamali podpisanych plików wykonywalnych — podmienili link na oficjalnej stronie. Użytkownicy wchodzili pod właściwy adres, strona wyglądała normalnie, złośliwy plik był obok legalnych plików aplikacji.
Kampania MacSync jest tym samym wzorcem jeden poziom wyżej w łańcuchu dystrybucji. Atakujący nie podmienili nic na stronie Homebrew — podmienili wynik w wyszukiwarce który do niej prowadzi. Użytkownicy wpisywali "Homebrew" w Google, klikali pierwszy wynik i byli na stronie która wyglądała dokładnie jak cel ich wyszukiwania.
Granica zaufania przesuwa się w górę: już nie "sprawdź czy jesteś na właściwej stronie" ale "sprawdź czy wynik wyszukiwania naprawdę prowadzi na właściwą stronę." W środowisku gdzie Google sprzedaje sponsorowane miejsca każdemu kto zapłaci — i gdzie weryfikacja reklamodawców jest niewystarczająca — ta granica jest trudna do utrzymania.
Co zrobić
Dla administratorów macOS w organizacjach: zablokowanie curl | sh na poziomie MDM dla standardowych kont użytkowników eliminuje cały łańcuch ataku. Sophos rekomenduje konfigurację profili MDM które blokują Terminala i interpretery poleceń dla kont niebędących administratorami, z warstwą Privacy Preferences Policy Control blokującą pełny dostęp do dysku dla Terminala.
Dla deweloperów z macOS: weryfikacja że pobierany skrypt pochodzi z raw.githubusercontent.com/Homebrew/install/HEAD/install.sh — a nie z żadnego innego adresu — przed wykonaniem. Wyszukiwanie Homebrew przez Google i klikanie pierwszego wyniku bez sprawdzenia URL jest ryzykowne.
Wskaźniki kompromitacji z kampanii z 30 kwietnia:
- SHA256 skryptu:
0d58616c750fc8530a7e90eee18398ddedd08cc0f4908c863ab650673b9819dd - SHA256 ładunku:
86d0c50cab4f394c58976c44d6d7b67a7dfbbb813fbcf622236e183d94fd944f - Domena C2:
glowmedaesthetics[.]com - Plik tymczasowy zbierania danych:
/tmp/osalogging.zip
Podsumowanie
Kampania MacSync przez fałszywą reklamę Homebrew nie jest nową techniką ataku — jest kolejną wariacją wzorca który cyberflux opisywał przez cały kwiecień. Atakujący nie atakują narzędzia. Atakują moment w którym użytkownik decyduje się je pobrać.
CPUID: podmieniony link na stronie producenta. Smart Slider: podmieniona aktualizacja przez oficjalny kanał. Homebrew: kupiona reklama w wyszukiwarce nad oficjalnym wynikiem. Za każdym razem granica zaufania jest inna, mechanizm ten sam.
Źródła
SANS ISC / Bradley Duncan — pierwotna analiza z 1 maja z IoC i łańcuchem infekcji: https://isc.sans.edu/diary/Malicious+Ad+for+Homebrew+Leads+to+MacSync+Stealer/32942
Cybernews — omówienie kampanii z kontekstem historycznym: https://cybernews.com/security/homebrew-malvertising-campaign-on-google-spread-infostealer/
SC Media — analiza ClickFix i wypowiedź ekspercka o problemie curl | sh: https://www.scworld.com/news/clickfix-campaigns-target-macos-users-via-macsync-infostealer
Daylight Security — szczegółowa analiza MacSync z mapą infrastruktury: https://daylight.ai/blog/macsync-stealer-returns-seo-poisoning
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł