Fałszywa rekrutacja instalowała malware na macOS

29 lipca 2026 roku Sekurak opublikował pierwszoosobowy opis rzeczywistego incydentu na macOS. Atak rozpoczął się od dopasowanej do profilu ofiary rozmowy rekrutacyjnej na LinkedIn. Po zbudowaniu zaufania rozmówca skierował kandydata do domeny podszywającej się pod Cisco Webex, a pobrany obraz DMG instruował, aby przeciągnąć element do Terminala.

Ten szczegół jest kluczowy. Malware nie musiało „magicznie przełamać” wszystkich zabezpieczeń macOS. Użytkownik został przekonany do uruchomienia polecenia w powłoce, co ominęło typową ścieżkę LaunchServices i oczekiwania związane z Gatekeeperem. Następnie atak ustanowił trwałość przez ~/Library/LaunchAgents, pobrał drugi etap wskazany przez rekord DNS TXT i wykonał kod JavaScript for Automation przez osascript -l JavaScript.

Co potwierdza źródło z 29 lipca

Opis Wojciecha Wilka opublikowany przez Sekurak dokumentuje incydent z perspektywy osoby, której urządzenie zostało zainfekowane. Potwierdzone elementy obejmują:

kontakt rekrutacyjny dopasowany do doświadczenia zawodowego;
użycie domeny cisco[.]us-webexmeet[.]com, która miała wyglądać jak usługa Webex;
pobranie pliku DMG z instrukcją „Drag into Terminal”;
utworzenie mechanizmu trwałości w katalogu użytkownika ~/Library/LaunchAgents;
pobieranie adresu kolejnego etapu z rekordu DNS TXT;
wykonanie drugiego etapu jako JXA przez osascript;
narażenie kluczy SSH, tokenów Git i chmury, sesji przeglądarki oraz lokalnych projektów;
izolację hosta, wyłączenie mechanizmu trwałości, unieważnienie sesji i pełne wymazanie urządzenia.

Opis nie identyfikuje publicznie konkretnej grupy przestępczej i nie daje podstaw do takiego przypisania. Podobieństwo do znanych kampanii „Contagious Interview” może być hipotezą analityczną, ale bez zgodnych wskaźników i niezależnej analizy próbki nie powinno być przedstawiane jako fakt.

Dlaczego dobrze przygotowana rekrutacja działa

Wiadomość nie wyglądała jak losowy spam. Atakujący odwołał się do prawdziwego profilu i stworzył proces, który naśladował oczekiwane etapy rekrutacji. Kandydat spodziewa się linku do rozmowy, zadania technicznego albo aplikacji konferencyjnej. Każdy z tych elementów może więc zostać wykorzystany jako uzasadnienie pobrania pliku.

Złośliwy proces nie musi wywoływać presji w stylu „zapłać w pięć minut”. Może działać wolniej: zadawać rozsądne pytania, używać języka branżowego i dopiero po zbudowaniu wiarygodności poprosić o nietypową czynność. To ważna lekcja dla szkoleń cyberbezpieczeństwa pracowników: symulacje powinny obejmować kontekst HR, GitHub, komunikatory i narzędzia deweloperskie, nie tylko faktury w e-mailu.

„Przeciągnij do Terminala” zmienia model zaufania

Typowa aplikacja pobrana z internetu otrzymuje atrybut kwarantanny. LaunchServices i Gatekeeper mogą wtedy sprawdzić podpis, notarization i reputację. Jeżeli jednak instrukcja nakłania użytkownika do skopiowania polecenia lub przeciągnięcia obiektu do powłoki, system widzi akcję wykonaną przez Terminal, któremu użytkownik już ufa.

Nie oznacza to, że każdy plik DMG może automatycznie ominąć Gatekeeper. Atak wykorzystuje różnicę między otwarciem aplikacji a świadomym wykonaniem tekstu lub skryptu w powłoce. Barierą staje się decyzja człowieka, dlatego ekran instalacji często wyświetla fałszywe wyjaśnienie: problem z uprawnieniami, konieczność „naprawy” połączenia albo krok wymagany przez zabezpieczenia firmy.

Zasada obronna jest prosta: legalne narzędzie do wideokonferencji nie powinno wymagać przeciągania elementu do Terminala, uruchamiania curl | sh, wyłączania Gatekeepera ani wklejania hasła administratora. Gdy rekruter prosi o taką czynność, proces należy przerwać i zweryfikować innym kanałem.

LaunchAgent daje trwałość bez roota

~/Library/LaunchAgents należy do użytkownika. Plik plist w tym katalogu może uruchamiać program po zalogowaniu bez uprawnień administratora. To pokazuje, dlaczego brak promptu hasła nie oznacza braku kompromitacji. Malware działające jako użytkownik może nadal czytać dostępne mu pliki, wykorzystywać aktywne sesje i komunikować się z usługami, do których użytkownik jest zalogowany.

W monitoringu warto obserwować:

nowe lub zmienione pliki w ~/Library/LaunchAgents;
launchctl bootstrap, load lub kickstart uruchamiane przez nietypowy proces;
procesy potomne Terminala, osascript, sh, bash i zsh;
uruchomienie artefaktu bez podpisu z katalogu Downloads lub zamontowanego DMG;
połączenie przeglądarki z domeną podobną do marki, po którym następuje wykonanie skryptu;
pliki plist wskazujące na ukryte katalogi użytkownika albo losowe nazwy.

Te sygnały nie są automatycznym dowodem infekcji. Administratorzy i legalne aplikacje także używają LaunchAgents. Skuteczna detekcja łączy czas utworzenia pliku, rodzica procesu, reputację binarki, połączenia sieciowe i kontekst użytkownika.

DNS TXT jako elastyczny kanał konfiguracji

Rekord TXT może przechowywać tekst dostępny przez DNS. Legalnie służy między innymi do SPF, DKIM, weryfikacji domen i konfiguracji usług. Atakujący może jednak zapisać w nim zakodowany adres lub parametr następnego etapu. Zyskuje dzięki temu warstwę pośrednią: implant nie musi zawierać stałego URL, a operator może zmienić kierunek pobierania bez publikowania nowej próbki.

Zablokowanie jednego rekordu nie rozwiązuje klasy problemu. Organizacja powinna logować zapytania DNS, wykrywać nietypowe TXT wykonywane przez stacje robocze i korelować je z procesem źródłowym. Mac użytkownika nie powinien rutynowo wykonywać wielu zapytań TXT do świeżo utworzonych domen bez związku z pocztą lub usługami firmowymi.

Należy też zachować ostrożność przy wskaźnikach. Publiczna domena z konkretnego incydentu może wygasnąć lub zostać przejęta do sinkholingu. Warto blokować ją w kontekście historycznym, ale detekcja zachowania jest trwalsza niż pojedyncza lista IOC.

JXA pozwala działać w pamięci

JavaScript for Automation to mechanizm macOS pozwalający sterować aplikacjami i korzystać z interfejsów systemowych poprzez JavaScript. osascript -l JavaScript uruchamia taki kod bez potrzeby kompilowania klasycznej aplikacji. W analizowanym incydencie drugi etap miał być wykonany w pamięci, co ogranicza liczbę oczywistych plików pozostawionych na dysku.

„Fileless” nie znaczy „niewidzialny”. Nadal istnieją:

proces osascript i jego linia poleceń;
drzewo procesów prowadzące od Terminala lub LaunchAgenta;
zapytania DNS i połączenia wychodzące;
odczyty pęku kluczy, katalogów przeglądarek i plików deweloperskich;
zdarzenia uruchomienia oraz zmiany mechanizmu trwałości.

EDR powinien traktować osascript jako narzędzie podwójnego zastosowania. Samo zablokowanie może zepsuć automatyzacje, lecz wykonywanie długiego, zakodowanego skryptu przez świeżo pobrany instalator jest mocnym sygnałem.

Dlaczego tokeny są pilniejsze niż hasła

Po infekcji naturalnym odruchem jest zmiana głównego hasła. To konieczne, ale niewystarczające. Aktywna sesja przeglądarki, token OAuth, klucz SSH lub token CLI może nadal działać bez ponownego wpisania hasła i czasami omija MFA. Dlatego sekwencja reakcji powinna uwzględniać rzeczywiste ścieżki dostępu.

Priorytetowa lista obejmuje:

izolację hosta od sieci;
zachowanie danych ulotnych i kopii istotnych artefaktów;
unieważnienie sesji SSO, poczty, GitHub/GitLab i chmury;
wycofanie kluczy SSH i tokenów osobistych;
rotację sekretów dostępnych w repozytoriach, .env, konfiguracjach CLI i historii powłoki;
sprawdzenie operacji wykonanych z tych tożsamości;
odbudowę lub pełne wymazanie urządzenia z zaufanego źródła.

Rotację należy prowadzić z czystego urządzenia. Wykonywanie jej na zainfekowanym Macu może ujawnić nowe poświadczenia atakującemu. Pomocny jest uporządkowany plan reagowania na incydenty, który rozdziela containment, analizę zakresu i odzyskiwanie.

Co powinien zrobić zespół IT i SOC

Najpierw wyszukaj opisane artefakty na wszystkich urządzeniach: domenę, nazwę DMG, LaunchAgent, polecenia osascript i zapytania DNS TXT. Następnie rozszerz poszukiwanie o zachowania podobne, ponieważ nazwy można łatwo zmienić. Sprawdź logowania do systemów deweloperskich i chmurowych po czasie możliwej infekcji, szczególnie z nowych adresów, urządzeń i lokalizacji.

Zespół powinien także przejrzeć politykę urządzeń deweloperskich. Klucze produkcyjne nie powinny być stale dostępne na laptopie. Tokeny muszą mieć krótki czas życia i minimalny zakres, a dostęp uprzywilejowany powinien wymagać ponownego uwierzytelnienia odpornego na phishing. Repozytoria i chmura powinny alarmować o nowym kluczu, zmianie ustawień bezpieczeństwa i masowym pobieraniu danych.

Warto przećwiczyć ten scenariusz w tabletop: HR otrzymuje zgłoszenie, użytkownik przyznaje, że wykonał polecenie, SOC izoluje host, IAM unieważnia sesje, a zespoły deweloperskie rotują zależne sekrety. Bez ćwiczenia najwięcej czasu traci się na ustalanie, kto może unieważnić token i które projekty były dostępne.

Źródło a wnioski BreachRoad

Fakty o przebiegu konkretnego incydentu, domenie, DMG, LaunchAgent, DNS TXT, JXA i podjętej reakcji pochodzą z pierwszoosobowej publikacji Sekuraka z 29 lipca 2026. Nie przypisujemy kampanii konkretnej grupie, ponieważ źródło nie daje wystarczającego potwierdzenia.

Hipotezy detekcyjne, kolejność rotacji, zalecenia EDR i ćwiczenie organizacyjne są wnioskami BreachRoad. Jeżeli firma używa Maców do rozwoju oprogramowania lub administracji chmurą, niech ten incydent będzie gotowym scenariuszem szkolenia i przeglądu. Największym ryzykiem nie jest sam laptop, lecz wszystkie zaufane systemy, do których jego użytkownik miał już otwartą sesję.

Jak zbudować detekcję odporną na zmianę domeny

IOC z konkretnego incydentu jest dobrym punktem startowym, ale napastnik może zmienić domenę, nazwę obrazu i plik LaunchAgenta w kilka minut. Reguły behawioralne powinny połączyć zdarzenia, które osobno mogą być legalne:

przeglądarka pobiera DMG krótko po wejściu z komunikatora lub portalu rekrutacyjnego;
użytkownik montuje obraz, a instrukcja prowadzi do Terminala zamiast podpisanej aplikacji;
osascript uruchamia JavaScript for Automation z nietypowego procesu nadrzędnego;
nowy plik pojawia się w ~/Library/LaunchAgents;
ten sam host odpytuje rekord TXT i chwilę później pobiera kolejną fazę;
proces czyta katalogi z konfiguracją chmury, kluczami SSH, repozytoriami i profilami przeglądarek.

Żadne z tych zdarzeń nie musi samodzielnie uzasadniać izolacji. Korelacja w krótkim oknie czasowym tworzy jednak znacznie mocniejszy sygnał. Zespół może opisać go jako hipotezę detekcyjną, przetestować kontrolowaną symulacją i przenieść do procesu detection engineering z Sigma i SIEM.

Granica między rekrutacją a zaufaniem technicznym

Proces rekrutacyjny nie powinien wymagać uruchamiania poleceń, omijania Gatekeepera ani instalowania nieznanego klienta spotkań. Organizacja może opublikować listę legalnych domen, nazw używanych narzędzi i zasad kontaktu kandydatów. Rekruter powinien mieć prostą ścieżkę zgłoszenia przejętego profilu lub podszycia.

Dla pracownika technicznego najważniejsza reguła brzmi: nowy kontakt społeczny nie może automatycznie stać się zaufanym dostawcą kodu. Nawet autentyczny profil LinkedIn może zostać przejęty. Weryfikacja powinna objąć domenę firmy znalezioną niezależnie, zaproszenie z oczekiwanego systemu i brak instrukcji „przeciągnij do Terminala”.

W razie wykonania polecenia przydatny jest plan reakcji na incydent i wyciek. Oprócz hosta obejmuje on konta Git, chmurę, menedżer haseł, pocztę i wszystkie aktywne sesje. Materiały w Akademii Breachroad pomagają pracownikom rozumieć te zależności bez odtwarzania malware.

Mierniki gotowości organizacji

Zespół może mierzyć czas od zgłoszenia użytkownika do izolacji urządzenia, unieważnienia sesji SSO, zablokowania domeny i identyfikacji sekretów. Warto również sprawdzić, jaki odsetek Maców raportuje uruchomienia osascript, czy EDR widzi katalogi użytkownika i czy IAM pozwala masowo odwołać tokeny. Te mierniki mówią więcej o odporności niż sama obecność produktu ochronnego.