Odpověď hned: Útok na ConnectWise Cloud Backup využil odcizené přihlašovací údaje důvěryhodné aplikace k přístupu do prostředí Microsoft 365. Firmy, které používají nebo dříve používaly ConnectWise či SkyKick, mají nejdříve uchovat logy a konfiguraci a potom prověřit aplikační identity, nové klíče, souhlasy a privilegované role. Samotná přítomnost aplikace ani úspěšné přihlášení ještě nedokazují únik dat.
Co Microsoft oznámil 21. října 2026
Dne 21. října 2026 Microsoft popsal aktivitu čínské skupiny Storm-0940 navazující na kompromitaci víceklientské aplikace ConnectWise. Útočníci podle zprávy Microsoft Security použili nástroj ARTEX k automatizaci přihlašování, průzkumu prostředí a následných operací.
Nešlo o zneužití chyby v Microsoft 365. Vstupem byly odcizené aplikační přihlašovací údaje a důvěra, kterou zákaznické tenanty dříve udělily aplikacím ConnectWise.
Microsoft zaznamenal pokusy o přístup k více než 2 250 tenantům. Automatizovaná aktivita dosahovala až 2 900 neúspěšných přihlášení za minutu. V některých napadených prostředích následovaly operace přes Microsoft Graph a změny aplikačních přihlašovacích údajů, identit, skupin nebo privilegovaných rolí.
Tato čísla neříkají, kolika firmám unikla data. Pokus o přihlášení, úspěšné ověření a skutečný přístup k e-mailům nebo souborům jsou tři odlišné události, které je nutné ověřovat samostatně.
Proč změna hesla uživatele nestačí
OAuth aplikace se nepřihlašuje jako zaměstnanec. Po schválení aplikace vznikne v Entra ID její místní aplikační identita, označovaná jako service principal. Ta může používat certifikát, tajný klíč nebo jiný aplikační údaj a pracovat s oprávněními, která jí správce udělil.
| Uživatelský účet | Aplikační identita |
|---|---|
| Přihlašuje se člověk | Přihlašuje se software |
| Používá heslo, passkey nebo MFA | Používá vlastní aplikační přihlašovací údaj |
| Události jsou vedené u uživatele | Události se hledají mezi přihlášeními service principals |
| Změna hesla může účet odříznout | Změna hesla zaměstnance aplikaci zpravidla neodpojí |
Útočníci proto nemuseli zaměstnance přesvědčit k potvrzení MFA. Nešlo o prolomení vícefaktorového ověření, ale o použití jiné identity a jiného způsobu autentizace. Praktické zabezpečení uživatelských účtů popisujeme také v článku MFA ve firmě: passkeys a FIDO2 místo SMS, ale u tohoto incidentu je nutné kontrolovat hlavně aplikační identity.
Kdy zásah neprovádět naslepo a co uděláme my
Podnikovou aplikaci nemažte bez předchozího uložení její konfigurace, oprávnění a identifikátorů. Naslepo neměňte ani všechny souhlasy a role, pokud nevíte, které z nich zajišťují zálohování, správu nebo jinou důležitou službu. Neověřené skripty s globálním oprávněním správce mohou rozsah incidentu ještě zvětšit.
Při odborném prověření postupujeme ve třech krocích:
- uchováme dostupné přihlašovací, auditní a aplikační záznamy;
- porovnáme oprávněné změny s neznámými klíči, souhlasy, vlastníky a rolemi;
- navrhneme omezení přístupu, obnovu důvěryhodných přihlašovacích údajů a další kontrolu prostředí.
Pokud nemáte jistotu, zda byl ConnectWise nebo SkyKick ve vašem tenantovi autorizován, můžeme za vás provést prověření bezpečnosti Microsoft 365.
Koho se kontrola týká
Kontrola je namístě u organizací, které používají nebo dříve používaly ConnectWise Cloud Backup, včetně služby dříve spojované se značkou SkyKick. Prověřit je potřeba také neaktivní integrace a tenanty spravované externím poskytovatelem IT služeb.
ITPro 20. října 2026 uvedl, že ConnectWise po zjištění incidentu odstavil služby Cloud Backup, SaaS Security a Cloud Management. Služby zůstávaly několik dní omezené.
Podle vyjádření ConnectWise citovaného ITPro zůstaly existující záložní archivy zašifrované, izolované a zachované. To však nevypovídá o stavu živého tenantu Microsoft 365. Dostupnost zálohy, bezpečnost aplikačních identit a případný přístup k provozním datům se musí posoudit odděleně.
Co uchovat před změnami
Nezačínejte smazáním podnikové aplikace. Nejdříve zaznamenejte její identitu a shromážděte důkazy, které mohou později ukázat, co se v tenantovi stalo.
Uložte zejména:
- Application ID a Object ID dotčené aplikace a jejího service principal;
- zobrazovaný název, vlastníky a vydavatele aplikace;
- udělená aplikační i delegovaná oprávnění;
- certifikáty, tajné klíče a data jejich vytvoření;
- app-role assignments a administrátorské souhlasy;
- přihlášení service principals;
- Entra audit logs a Microsoft Purview Audit;
- související záznamy ze SIEM a dostupnou telemetrii Microsoft Graph.
Název aplikace není spolehlivý identifikátor. Lze jej změnit nebo zaměnit s jinou aplikací, proto kontrolujte především Application ID a objekt v konkrétním tenantovi.
Microsoft doporučil prověřit aktivitu nejméně od 15. října 2026. Pokud máte delší historii záznamů, rozšiřte kontrolu aplikačních identit až k 1. říjnu 2026. Skutečně dostupné období závisí na licencích, nastavení auditu a době uchování logů.
Co hledat v Entra ID
Nejdříve oddělte neúspěšné pokusy od úspěšných přihlášení. U každé úspěšné události zjistěte, která aplikace se ověřila, odkud požadavek přišel, jaký prostředek byl cílem a zda následovala další činnost.
V přihlášeních service principals kontrolujte:
- aktivitu mimo očekávanou infrastrukturu dodavatele;
- nezvyklé zdrojové adresy a časové vzorce;
- velké série neúspěšných pokusů;
- úspěšné přihlášení následované voláním Microsoft Graph;
- přístup aplikace, která už neměla být aktivní.
Kontrolu neomezujte pouze na zveřejněné IP adresy. Infrastruktura útočníka se může měnit a legitimní provoz dodavatele může používat více adres.
V Entra audit logs hledejte zejména:
- přidání nového tajného klíče nebo certifikátu;
- změnu vlastníků aplikace;
- vytvoření nového service principal;
- nový administrátorský souhlas;
- nové app-role assignments;
- přiřazení privilegované adresářové role;
- změny uživatelů, skupin a metod ověřování;
- změny zásad Conditional Access.
Každý nález porovnejte s tiketem, změnovým požadavkem nebo potvrzenou činností správce. Přehled oprávnění by neměl končit jen seznamem globálních správců; postup rozšiřujeme v článku Audit přístupových práv ve firmě.
Co ověřit v Microsoft Purview
Úspěšné ověření aplikace ještě neříká, zda někdo pracoval s firemními daty. Pro tuto část kontroly slouží auditní záznamy Microsoft 365 a Purview.
Hledejte především:
- neobvyklý přístup k poštovním schránkám;
- čtení nebo stahování většího množství souborů;
- nové delegace ke schránkám;
- vytvoření pravidel doručené pošty;
- nová přeposílání na externí adresy;
- změny transportních pravidel;
- přístup k SharePointu nebo OneDrivu mimo běžný provoz.
Pokud najdete zásah do uživatelského účtu nebo schránky, pokračujte podle checklistu Napadený účet Microsoft 365: první kroky. Samotná aplikační událost ale není důkazem, že byly e-maily nebo dokumenty přečteny či odneseny.
Proč nestačí původní aplikaci odpojit
Microsoft popsal případy, kdy po získání přístupu následovaly změny aplikačních přihlašovacích údajů a oprávnění. Útočník mohl přidat nový klíč, vlastníka, souhlas, aplikační identitu nebo privilegovanou roli.
Zakázání původního spojení zabrání jeho dalšímu použití, ale samo nevrátí změny, které již v tenantovi proběhly. Po omezení ConnectWise proto prověřte i ostatní aplikační identity a privilegované objekty vytvořené nebo změněné v relevantním období.
Po uchování důkazů je potřeba řešit dvě věci odděleně:
- zneplatnit nedůvěryhodné cesty přístupu;
- ověřit, zda nezůstala další forma perzistence.
Pouhé přejmenování aplikace, změna hesel zaměstnanců nebo kontrola seznamu uživatelů tento úkol neřeší.
Co chtít po dodavateli zálohování
Dodavatel nebo správce služby by měl být schopen doložit:
- které aplikace a service principals do tenantu nasadil;
- jejich Application ID a požadovaná oprávnění;
- proč jednotlivá oprávnění potřebuje;
- kdo a kdy udělil administrátorský souhlas;
- jak se sleduje přidání klíče, certifikátu, vlastníka nebo role;
- jak dlouho jsou uchovávány Entra a Purview logy;
- jak proběhne obnova při nedostupnosti zálohovací služby;
- zda obnova nezávisí na stejné aplikační identitě, která je předmětem incidentu.
Výpis „záloha proběhla úspěšně“ potvrzuje provedení úlohy, nikoli obnovitelnost celého prostředí. Rozdíl mezi existující zálohou a ověřenou obnovou vysvětluje článek Zálohu jste nikdy nezkusili obnovit: test obnovy.
Praktický kontrolní seznam
- Zjistěte, zda tenant používá nebo dříve používal ConnectWise Cloud Backup či SkyKick.
- Identifikujte aplikaci podle Application ID, ne pouze podle názvu.
- Uchovejte konfiguraci aplikace, přihlášení a auditní záznamy.
- Oddělte neúspěšná a úspěšná přihlášení service principals.
- Prověřte nové klíče, certifikáty, vlastníky, souhlasy a role.
- V Purview ověřte případnou práci s poštou, soubory a pravidly.
- Každou změnu porovnejte s oprávněnou administrátorskou činností.
- Teprve potom odstraňte nedůvěryhodný přístup a obnovte potřebné integrace.
- Otestujte, zda lze zálohu skutečně obnovit i při výpadku dodavatele.
Časté otázky
Znamená nalezená aplikace ConnectWise, že unikla data?
Ne. Přítomnost aplikace ani úspěšné ověření samy o sobě nedokazují přístup k e-mailům nebo souborům. Ten musí potvrdit navazující auditní události.
Stačí změnit hesla uživatelů?
Ne. Aplikační identita používá vlastní přihlašovací údaje. Změna hesla zaměstnance její přístup zpravidla neovlivní.
Máme aplikaci okamžitě smazat?
Nejdříve uchovejte její identifikátory, konfiguraci, oprávnění a dostupné logy. Potom lze spojení bezpečně omezit a zkontrolovat, zda nevznikla další cesta přístupu.
Co když jsme SkyKick používali před několika lety?
Prověřte také dříve autorizované a nyní neaktivní integrace. Pokud už aplikaci v portálu nevidíte, projděte dokumentaci dodavatele, předávací protokoly a dostupné auditní záznamy.
Jsou zálohy po incidentu nepoužitelné?
Z veřejných informací to nevyplývá. ConnectWise uvedl, že záložní archivy zůstaly zachované, zatímco dostupnost některých služeb byla omezená. Obnovitelnost záloh a bezpečnost živého tenantu je přesto nutné ověřit samostatně.