Złośliwe repozytoria Next.js atakują deweloperów

Wprowadzenie: dlaczego to ma znaczenie

Stacje robocze deweloperów i środowiska build są celami o wysokiej wartości, ponieważ często przechowują kod źródłowy, materiały do podpisywania oraz sekrety (tokeny API, poświadczenia chmurowe) w zmiennych środowiskowych. Microsoft Defender Experts opisuje kampanię polegającą na „zasiewaniu” złośliwych repozytoriów Next.js—często opakowanych jako rekrutacyjne zadania „take-home”—zaprojektowanych tak, aby wtopić się w typowe przepływy pracy deweloperów i niezawodnie wyzwalać wykonanie kodu.

Co nowego / kluczowe ustalenia

Microsoft zaobserwował wiele powiązanych repozytoriów ze wspólnymi konwencjami nazewnictwa i ponownie wykorzystywaną logiką loadera. Choć początkowa przynęta bywa różna, efekt końcowy jest spójny: pobranie w czasie działania i wykonanie w pamięci JavaScript kontrolowanego przez atakującego, a następnie przejście do etapowego C2.

1) Wykonanie w przestrzeni roboczej VS Code przy otwarciu folderu

Niektóre repozytoria zawierają .vscode/tasks.json skonfigurowany z runOn: "folderOpen". Jeśli deweloper otworzy projekt (i go „zaufa”), zadanie uruchamia się automatycznie i startuje skrypt Node, który pobiera loader JavaScript (zaobserwowany jako etapowany na Vercel) i go wykonuje.

2) Wykonanie na etapie build podczas uruchamiania aplikacji

Inne warianty aktywują się, gdy deweloper uruchamia projekt (np. npm run dev). Te repozytoria osadzają złośliwą logikę w pozornie normalnych zasobach (np. trojanizowany jquery.min.js). Zasób dekoduje URL w base64, pobiera loader (ponownie, często z Vercel) i wykonuje go w pamięci.

3) Wykonanie przy starcie backendu z eksfiltracją env + dynamicznym RCE

Trzecia ścieżka aktywuje się podczas inicjalizacji serwera/importu modułu. Repozytoria mogą zawierać wartość .env typu AUTH_API=<base64>. Przy starcie kod backendu dekoduje endpoint, wysyła process.env do atakującego, a następnie wykonuje zwrócony JavaScript przy użyciu dynamicznej kompilacji (np. new Function("require", response.data)(require)). To może ujawnić wrażliwą konfigurację i umożliwia operatorowi dostarczanie kolejnych payloadów.

Rejestracja Stage 1 → etapowy command-and-control

Niezależnie od ścieżki, wykonanie zbiega się w początkowym etapie „registrar”, który profiluje hosta i odpyta endpoint rejestracji, otrzymując instanceId do korelacji dalszej aktywności. Telemetria wskazała też trwałe callbacki do infrastruktury kontrolowanej przez atakujących (w tym ruch HTTP na porcie 300) po początkowym etapowaniu.

Wpływ dla administratorów IT i zespołów bezpieczeństwa

• Wyższe ryzyko na endpointach deweloperskich: Samo otwarcie repo może wystarczyć do wykonania kodu, jeśli zadaniom workspace zostanie nadane zaufanie.
• Ekspozycja poświadczeń: Ścieżka startu backendu może eksfiltrować zmienne środowiskowe (klucze chmurowe, poświadczenia baz danych, tokeny CI).
• Trudniejsza detekcja: Wykonanie w pamięci i etapowane loadery mogą ograniczać oczywiste artefakty na dysku.

Działania / kolejne kroki

• Wytyczne dla deweloperów: Traktuj zadania „take-home” i nieznane repozytoria jako niezaufane; unikaj kliknięcia „Trust” w VS Code, dopóki projekt nie zostanie przejrzany.
• Inspekcja repo: Oznaczaj/sprawdzaj .vscode/tasks.json (szczególnie runOn: "folderOpen"), nieoczekiwane skrypty Node w .vscode/ oraz zminifikowane biblioteki, które nie pasują do znanych dobrych hashy.
• Higiena sekretów: Ogranicz zależność od długowiecznych sekretów w .env; tam, gdzie to możliwe, używaj managed identities/krótkotrwałych tokenów i rotuj wszelkie ujawnione poświadczenia.
• Detekcja i kontrola: Monitoruj procesy Node.js pod kątem nietypowych połączeń wychodzących (np. narzędzia dev łączące się z domenami staging, a następnie z nieznanym C2) oraz rozważ ograniczenia egress z urządzeń deweloperskich i agentów build.
• Hunting: Przeszukuj hosting kodu i wewnętrzne mirrory pod kątem „rodzin” nazw i wzorców ponownego użycia struktury opisanych przez Microsoft (niemal-duplikaty repozytoriów, podobne loadery, powtarzające się endpointy staging).