SOC Prime Bias: Critical

20 Oct 2026 12:39 UTC

Poświadczenia sprzedawcy ConnectWise SkyKick wykorzystywane w atakach na Microsoft 365

Author Photo
SOC Prime Team linkedin icon Śledź
Poświadczenia sprzedawcy ConnectWise SkyKick wykorzystywane w atakach na Microsoft 365
shield icon

Detection stack

  • AIDR
  • Alert
  • ETL
  • Query

Podsumowanie

Skonfliktowany tajny klucz API Microsoftu 365 związany z ConnectWise Cloud Backup, wcześniej SkyKick, został wykorzystany przez cyberprzestępców do uzyskania nieautoryzowanego dostępu do środowisk M365 klientów. Atakujący wykorzystali szerokie uprawnienia aplikacji do uzyskania dostępu do Exchange Online, Microsoft Teams i SharePoint Online. Działanie obejmowało zarówno zautomatyzowane żądania tokenów, jak i ręczne operacje poeksploatacyjne.

Śledztwo

Huntress zidentyfikował nadużycie głównych usług ConnectWise w logach logowania do Microsoft 365, w tym nieautoryzowany dostęp z adresu IP dostawcy hostingu 144.172.64.128 i prywatnej przestrzeni IPv6 Azure. Śledztwo wykazało, że atakujący użyli przejętych poświadczeń, aby przypisać role katalogowe takie jak Globalny Administrator i dodać nowe tajne klucze klientów do innych zaufanych aplikacji w celu utrzymania dostępu. Działanie obejmowało także skrypty do przemieszczania się po najemcach w kolejności GUID i wyraźne wzorce User-Agent.

Łagodzenie

Organizacje powinny niezwłocznie wyłączyć usunięte aplikacje ID ConnectWise Cloud Backup i ConnectWise Cloud Management w swoich tenantach Microsoft 365. Wyłączenie zamiast usunięcia aplikacji jest ważne dla zachowania zarządzania zgodami. Zespoły bezpieczeństwa powinny również przeprowadzić audyt wszystkich logowań głównych usług i sprawdzić poświadczenia aplikacji pod kątem nieoczekiwanych dodatków utworzonych od 13 października.

Reakcja

Kiedy zostanie zidentyfikowana podejrzana aktywność, organizacje powinny przeglądać logi audytowe Entra dla Dodaj członka do roli, Aktualizuj aplikację, oraz Dodaj poświadczenia głównej usługi zdarzeń. Zespoły bezpieczeństwa powinny zweryfikować powiązane ciągi User-Agent i rozróżnić legalne działania dostawców, takie jak kiota-dotnet, od narzędzi atakujących, w tym Python-urllib i curl. Na koniec, przejrzyj wszystkie tajne klucze klientów i certyfikaty w aplikacjach przedsiębiorstwa i usuń jakiekolwiek nieautoryzowane poświadczenia.

Przebieg ataku

Wciąż aktualizujemy tę część.

Wykrycia

Dodaj użytkownika do roli admina (przez office365)

Zespół SOC Prime
19 października 2026

Aktualizacja poświadczeń konta głównej usługi (przez azuread)

Microsoft, Zespół SOC Prime
19 października 2026

Wysokoprzywilejowa rola została przypisana (przez azuread)

Zespół SOC Prime
19 października 2026

IOC (SourceIP) do wykrycia: Nadużycie poświadczeń dostawcy ConnectWise (SkyKick) w atakach M365

Zasady AI SOC Prime
19 października 2026

IOC (DestinationIP) do wykrycia: Nadużycie poświadczeń dostawcy ConnectWise (SkyKick) w atakach M365

Zasady AI SOC Prime
19 października 2026

Wykrywaj nieautoryzowane modyfikacje w M365 za pomocą Python-urllib [Azure Activity Logs]

Zasady AI SOC Prime
19 października 2026

Nieautoryzowane użycie tokenów Microsoft Graph w M365 za pomocą aplikacji ConnectWise [Azure Auditlogs]

Zasady AI SOC Prime
19 października 2026

Wykonanie symulacji

  • Narracja ataku i polecenia: Atakujący zdołał uzyskać dostęp do głównego konta usługowego z ograniczonymi uprawnieniami. Aby osiągnąć utrzymanie i pełną kontrolę nad środowiskiem, atakujący wykonuje skrypt Pythona. Skrypt celuje w interfejs API Microsoft Graph, aby: 1) Dodać przejętego głównego użytkownika serwisowego do roli katalogowej o wysokich uprawnieniach (np. Globalny Administrator lub Administrator Ról Wysokoprzywilejowanych), oraz 2) Dodać nowy tajny klucz klienta do głównego konta usługowego. Atakujący używa urllib bibliotekę w Pythonie 3.12, która domyślnie używa Python-urllib/3.12 User-Agent, zapewniając specyficzny hook telemetryczny wymagany przez regułę wykrywania.

  • Skrypt testów regresji:

    import urllib.request
    import json
    
    # UWAGA: Ten skrypt to symulacja struktury wywołania API.
    # W realnym środowisku wymagany byłby poprawny token OAuth2 Bearer.
    # Ten skrypt ma na celu wywołanie logiki wykrywania 'UserAgent' i 'OperationName'.
    
    target_url = "https://graph.microsoft.com/v1.0/directoryRoles"
    access_token = "SYMULOWANY_TOKEN"
    
    headers = {
        "Authorization": f"Bearer {access_token}",
        "Content-Type": "application/json"
    }
    
    # Ten konkretny User-Agent jest bodźcem dla reguły wykrywania
    user_agent = "Python-urllib/3.12"
    
    # Symulacja "Dodaj członka do roli"
    payload = {
        "roleId": "target-role-guid",
        "principalId": "attacker-service-principal-guid"
    }
    
    print(f"[*] Symulacja nieautoryzowanej modyfikacji roli przy użyciu {user_agent}...")
    
    try:
        req = urllib.request.Request(
            target_url, 
            data=json.dumps(payload).encode('utf-8'), 
            headers=headers, 
            method='POST'
        )
        req.add_header('User-Agent', user_agent)
    
        # W prawdziwym teście, to wywołanie zrealizowałoby rzeczywiste API.
        # Dla celów symulacji zakładamy, że wywołanie API jest skuteczne w celu wygenerowania logu.
        print("[+] Żądanie wysłane. Sprawdź Dzienniki Audytu Azure dla 'Dodaj członka do roli' z User-Agent: Python-urllib/3.12")
    except Exception as e:
        print(f"[-] Symulacja nie powiodła się: {e}")
  • Polecenia czyszczenia:

    # Ręczne czyszczenie jest wymagane w M365, ponieważ są to zmiany na poziomie tożsamości.
    # 1. Usuń przypisanie dodanej roli:
    # Remove-MgDirectoryRoleMemberByRef -DirectoryRoleId <ID> -DirectoryRoleMemberId <ID>
    
    # 2. Usuń dodane poświadczenia głównego konta usługowego:
    # Remove-MgServicePrincipalPassword -ServicePrincipalId <ID> -PasswordId <ID>