ConnectWise Cloud Backup: credencial expõe 173 tenants

Neste artigo do Blog Dolutech, vamos analisar em profundidade um dos incidentes de cadeia de suprimentos mais relevantes de 2026 até agora: o comprometimento da credencial do aplicativo ConnectWise Cloud Backup, antigo SkyKick Backup, que permitiu a um ator ainda não identificado autenticar-se em pelo menos 173 tenants do Microsoft 365 de parceiros e clientes, sem digitar uma única senha e sem disparar um único prompt de MFA.

O caso é emblemático porque não envolve exploit, malware ou phishing contra usuários finais. O atacante simplesmente passou a operar como o próprio aplicativo de backup, herdando todas as permissões que milhares de administradores haviam concedido de boa-fé. Para quem gere ambientes Microsoft 365, especialmente MSPs que administram dezenas ou centenas de clientes, este é um alerta direto: a identidade de aplicações é hoje uma superfície de ataque tão crítica quanto a identidade de pessoas.

Ao longo deste conteúdo, nós vamos detalhar a linha do tempo, o mecanismo técnico do abuso, o mapeamento MITRE ATT&CK, os indicadores publicados, scripts de detecção e mitigação em PowerShell e KQL, e as implicações regulatórias para organizações sujeitas a NIS2, DORA, GDPR e LGPD.

O que aconteceu com o ConnectWise Cloud Backup

O ConnectWise Cloud Backup é um serviço de backup cloud-to-cloud voltado para MSPs, que protege dados de Microsoft 365 e Google Workspace dos clientes desses provedores. O produto chegou ao portfólio da ConnectWise com a aquisição da SkyKick, anunciada em 2024, e em muitos tenants ainda aparece com o nome antigo.

A empresa de segurança Huntress publicou em 16 de outubro de 2026 uma investigação confirmando que um segredo de API pertencente ao aplicativo Microsoft 365 do Cloud Backup estava em mãos hostis. Com ele, o atacante obteve tokens de acesso ao Microsoft Graph em tenants de clientes. A contagem confirmada chegou a 162 tenants na noite de 16 de outubro e subiu para 173 no dia seguinte. A Todyl, outra fornecedora de MXDR, chegou de forma independente às mesmas conclusões em seus ambientes monitorados.

A Microsoft Threat Intelligence também se pronunciou publicamente, classificando o caso como um ataque ativo à cadeia de suprimentos no qual o aplicativo OAuth confiável foi usado para obter tokens em tenants de clientes, provavelmente explorando permissões altamente privilegiadas como Directory.ReadWrite.All.

A ConnectWise, por sua vez, confirmou acesso não autorizado a identidades de aplicação dentro do ambiente do Cloud Backup e desligou completamente o acesso do aplicativo até nova ordem. A empresa afirma não ter encontrado evidências de comprometimento dos dados de backup armazenados pelos parceiros. Como consequência direta, backups e restaurações de Microsoft 365 estão pausados para toda a base de clientes, e até a data de publicação deste artigo, 18 de outubro, não havia previsão pública de restabelecimento.

Por que um aplicativo de backup tem tanto poder

Para copiar e restaurar dados, um serviço de backup precisa ler e escrever em praticamente tudo: caixas de correio do Exchange Online, arquivos do OneDrive e SharePoint, conversas do Teams e informações do diretório. Segundo a análise da Todyl, o consentimento do aplicativo inclui leitura e escrita de e-mails e anexos (com acesso completo às caixas via Exchange Web Services), arquivos e chats, além da capacidade de restaurar dados no tenant.

Esse acesso é do tipo app-only, ou seja, não depende de nenhum usuário autenticado e não está limitado a uma única caixa de correio. Uma vez emitido o token, todo o tenant fica ao alcance de quem o detém. E como se trata de um aplicativo multilocatário, uma única credencial do fornecedor funciona em todos os tenants onde o app recebeu consentimento. É exatamente esse efeito multiplicador que transforma o vazamento de um único segredo em um incidente de escala.

Linha do tempo do incidente

A Dolutech consolidou a sequência de eventos a partir das publicações da Huntress, da Todyl, da Microsoft e da ConnectWise. Todos os horários estão em UTC.

Como funcionou o ataque: abuso de identidade de aplicativo OAuth

Client credentials flow e client assertion

Aplicativos multilocatários no Microsoft Entra ID provam sua identidade com um client secret ou um certificado mantido pelo publicador. No fluxo OAuth 2.0 client credentials, o aplicativo apresenta essa credencial ao Entra ID e recebe um token app-only para o recurso desejado, neste caso o Microsoft Graph.

O que o atacante fez foi replicar esse comportamento com ferramentas próprias. Os registros de login mostram o tipo de credencial clientAssertion, o que indica que o segredo vive no tenant do próprio fornecedor. Em outras palavras, nada do que o cliente fez no seu ambiente poderia ter produzido ou evitado essa autenticação. A origem do vazamento está do lado da ConnectWise, e a causa raiz ainda não foi divulgada.

O padrão de varredura, em ordem estritamente crescente de GUID de tenant, aponta para um script percorrendo uma lista pré-ordenada de tenants com consentimento. A Todyl observou um único token por tenant, em vez do padrão recorrente de um job de backup legítimo, o que reforça a hipótese de automação de reconhecimento em larga escala.

Por que MFA e Acesso Condicional não ajudaram

Este é o ponto que mais precisa ser compreendido pelas equipes de segurança. Autenticações app-only não envolvem usuário, dispositivo ou desafio de MFA. Políticas de Acesso Condicional voltadas a usuários simplesmente não se aplicam, e os logs da Todyl registram o status de Acesso Condicional como notApplied.

Além disso, revogar sessões de usuários não encerra esse acesso. Desabilitar o aplicativo no tenant impede a emissão de novos tokens, mas os tokens já emitidos podem permanecer válidos por até 90 minutos. E qualquer tenant em que o app continue habilitado segue exposto até que a ConnectWise rotacione a credencial comprometida.

O acesso condicional para workload identities existe, mas exige licenciamento adicional e, segundo a Todyl, não pode ser aplicado a aplicativos multilocatários de terceiros. Na prática, para esse tipo de app, os controles reais são consentimento com menor privilégio, inventário rigoroso e remoção de aplicativos sem uso.

Escalada para Global Administrator e persistência

O achado mais grave apareceu em um tenant de parceiro da Huntress. O aplicativo ConnectWise Cloud Management, MS Teams, se atribuiu a função Global Administrator e, em cerca de cinco minutos, executou um script com User-Agent Python-urllib/3.12 que fez nove alterações em dois outros aplicativos: uma ferramenta de gestão de MSP e a própria aplicação da plataforma Huntress. Seis alterações tiveram sucesso. Uma tentativa de adicionar certificado falhou por divergência de thumbprint, mas os client secrets adicionados em seguida funcionaram, com validade até 2028.

Nós destacamos aqui a lógica do atacante: um client secret em um aplicativo de gestão de MSP pode estender o acesso para além daquele tenant, porque esses aplicativos costumam ter consentimento nos tenants dos clientes do MSP. E uma credencial em um aplicativo de segurança concede ao seu portador tudo o que aquela ferramenta pode fazer. Cada passo cria um novo caminho de retorno que não depende mais da credencial original da ConnectWise. Por isso, rotacionar a credencial do fornecedor é necessário, mas não suficiente.

Um detalhe importante: essa atividade de persistência ocorreu cerca de duas horas e meia antes das primeiras autenticações a partir de 144.172.64[.]128 e partiu de espaço IPv6 privado do Azure. A Huntress ainda não vinculou as duas fases ao mesmo operador, e o mesmo intervalo de endereços também é usado por tráfego legítimo, o que impede tratar o endereço isoladamente como prova.

A segunda onda: alvos estratégicos

Em atualização de 17 de outubro, a Huntress identificou uma segunda onda, mais estreita e direcionada, partindo do mesmo IP contra 16 tenants dos setores de política, segurança nacional, comércio e minerais críticos. A maioria desses tenants nem utiliza produtos ConnectWise, e as tentativas falharam justamente porque o service principal não existia ali.

A primeira varredura dessa onda buscou tokens do Graph via aplicativo SkyKick. A segunda, no mesmo dia, pareceu manual e mirou Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra e as APIs de gestão do Office 365. A Huntress também relatou quase mil tenants do Entra com atividade de login vinda do IP associado, das quais mais de 300 foram bem-sucedidas, embora a ausência do service principal tenha impedido o acesso efetivo em parte deles.

Esse perfil de alvos não prova atribuição, mas muda a leitura do caso. O que começa parecendo uma operação oportunista de coleta passa a sugerir interesse em setores de valor estratégico. A Dolutech recomenda tratar o incidente com essa possibilidade em mente até que a investigação avance.

O que ainda não foi confirmado

A transparência sobre lacunas é essencial para uma resposta bem calibrada. Até o momento:

• Atribuição: o ator não foi identificado publicamente.
• Causa raiz: não se sabe como o segredo foi obtido no ambiente da ConnectWise.
• Exfiltração: no tenant analisado em detalhe pela Huntress, não há registro de acesso a e-mails ou arquivos. Porém, leituras de diretório via Microsoft Graph não deixam trilha de auditoria. Nos tenants com assinatura ativa de backup, a Todyl observou leituras que não podem ser atribuídas nem ao atacante nem ao serviço legítimo, já que ambos usam a mesma identidade de aplicação.
• Demais aplicativos: não há garantia de que os outros aplicativos ConnectWise de alto privilégio estejam seguros.

A conclusão prática é clara: ausência de evidência de exfiltração, aqui, é em grande parte uma limitação de visibilidade. Toda organização afetada deve tratar seus dados como potencialmente expostos.

Mapeamento MITRE ATT&CK

As técnicas T1078.004, T1098.003 e T1098.001 foram explicitamente associadas pela Huntress. As demais refletem o mapeamento da Dolutech a partir do comportamento descrito pelas fontes. As técnicas de coleta estão marcadas como potenciais porque não há confirmação pública de exfiltração.

Indicadores de Comprometimento (IoCs)

Nota de transparência da Dolutech: este incidente não envolve malware, portanto não há hashes de arquivos publicados. Os Application IDs listados pertencem a aplicativos legítimos: não devem ser bloqueados como indicador, e sim ter seus service principals desabilitados no tenant. Os User-Agents são comuns em administração rotineira e só têm valor quando correlacionados com IP, Application ID e operações como adição de credenciais ou atribuição de funções. Recomendamos acompanhar as atualizações da Huntress, da Todyl e da ConnectWise, pois os indicadores ainda estão em evolução.

Como detectar no seu ambiente

O primeiro ponto de atenção é operacional: no Microsoft Entra admin center, a aba padrão de logins de usuário não exibe essa atividade. É preciso acessar Monitoring, Sign-in logs, aba Service principal sign-ins, e filtrar pelo Application ID. O tráfego legítimo do aplicativo sai de IPv6 privado do Azure, então qualquer IP público fora das faixas Microsoft merece investigação.

Para quem usa Microsoft Sentinel ou envia logs do Entra para um Log Analytics Workspace, as consultas abaixo cobrem os principais comportamentos observados.

Consulta KQL: logins de service principal suspeitos

// Logins dos apps ConnectWise/SkyKick a partir de IPs fora do espaço privado do Azure
let ConnectWiseApps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae",
    "2399d300-6fca-4e6a-a686-399fefe75b83",
    "24205314-2b89-4e07-a2a4-579e898a5640",
    "b78f6a77-d4e5-46fb-87e5-d1648bd02519",
    "0de14c77-b9b0-4137-9360-34878a929827",
    "412dcf96-176d-4b3a-a1b0-4981ad66971e",
    "b2b55f5b-7758-4719-8d8f-88ae172e6bdb"
]);
AADServicePrincipalSignInLogs
| where TimeGenerated >= datetime(2026-10-01)
| where AppId in (ConnectWiseApps) or IPAddress == "144.172.64.128"
| extend IsAzurePrivateV6 = IPAddress startswith "fd"
| where IsAzurePrivateV6 == false
| project TimeGenerated, ServicePrincipalName, AppId, IPAddress,
          ResourceDisplayName, ResultType, ClientCredentialType, Location
| order by TimeGenerated asc

Consulta KQL: atribuição de funções e novas credenciais

// Service principals que atribuem funções a si mesmos ou alteram credenciais de outros apps
AuditLogs
| where TimeGenerated >= datetime(2026-10-13)
| where OperationName in ("Add member to role", "Add service principal credentials", "Update application")
      or OperationName has "Certificates and secrets"
| extend InitiatorApp   = tostring(InitiatedBy.app.displayName),
         InitiatorAppId = tostring(InitiatedBy.app.appId),
         Target         = tostring(TargetResources[0].displayName),
         UserAgent      = tostring(AdditionalDetails[0].value)
| where isnotempty(InitiatorAppId)
| project TimeGenerated, OperationName, InitiatorApp, InitiatorAppId, Target, Result, UserAgent
| order by TimeGenerated asc

A segunda consulta é útil mesmo fora deste incidente: um service principal que se adiciona a uma função de diretório ou modifica outros aplicativos é um comportamento incomum na maioria dos tenants e merece investigação por si só.

Mitigação: passo a passo técnico

Os scripts abaixo usam o módulo Microsoft Graph PowerShell. Execute-os com uma conta administrativa, preferencialmente em estação de trabalho privilegiada, e revise a saída antes de aplicar qualquer remoção.

1. Desabilitar, sem excluir, os service principals ConnectWise e SkyKick

A orientação de Huntress e Todyl é unânime: desabilite, não exclua. Excluir remove o consentimento e obriga a um novo processo de consentimento para restaurar o serviço. Desabilitar pausa os backups automáticos, mas não apaga os backups já armazenados pela ConnectWise.

# Requer: Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Application.ReadWrite.All","Directory.Read.All"

$AppIds = @(
    "506e08f9-6e9a-4da4-942b-a099a03644ae", # ConnectWise Cloud Backup
    "2399d300-6fca-4e6a-a686-399fefe75b83", # Cloud Management
    "24205314-2b89-4e07-a2a4-579e898a5640", # Cloud Management - MS Teams
    "b78f6a77-d4e5-46fb-87e5-d1648bd02519", # Cloud Management - Exchange Online
    "0de14c77-b9b0-4137-9360-34878a929827", # Cloud Management - MS Graph
    "412dcf96-176d-4b3a-a1b0-4981ad66971e", # Cloud Management - Partner Center
    "b2b55f5b-7758-4719-8d8f-88ae172e6bdb"  # Cloud Management - SharePoint Online
)

foreach ($id in $AppIds) {
    $sp = Get-MgServicePrincipal -Filter "appId eq '$id'" -ErrorAction SilentlyContinue
    if ($sp) {
        Update-MgServicePrincipal -ServicePrincipalId $sp.Id -AccountEnabled:$false
        Write-Host "[DESABILITADO] $($sp.DisplayName) ($id)" -ForegroundColor Yellow
    } else {
        Write-Host "[AUSENTE] $id nao encontrado neste tenant"
    }
}

# Busca adicional por nome, para apps antigos exibidos como "SkyKick Cloud Manager"
Get-MgServicePrincipal -All -Property Id,AppId,DisplayName,AccountEnabled,AppOwnerOrganizationId |
    Where-Object { $_.DisplayName -match "SkyKick|ConnectWise" -or
                   $_.AppOwnerOrganizationId -eq "3f9cd7a0-127a-4ed4-bf06-2f830d5616b7" } |
    Select-Object DisplayName, AppId, AccountEnabled

2. Auditar credenciais adicionadas a qualquer aplicativo desde 13 de outubro

Desabilitar os aplicativos ConnectWise não remove segredos já plantados em outros aplicativos. Este é o passo que mais vemos ser negligenciado em incidentes desse tipo.

Connect-MgGraph -Scopes "Application.Read.All"
$Desde = [datetime]"2026-10-13T00:00:00Z"
$Resultado = @()

$Objetos  = Get-MgApplication -All -Property Id,AppId,DisplayName,PasswordCredentials,KeyCredentials |
            Select-Object *, @{n="Tipo";e={"App registration"}}
$Objetos += Get-MgServicePrincipal -All -Property Id,AppId,DisplayName,PasswordCredentials,KeyCredentials |
            Select-Object *, @{n="Tipo";e={"Service principal"}}

foreach ($o in $Objetos) {
    foreach ($c in $o.PasswordCredentials) {
        if ($c.StartDateTime -ge $Desde) {
            $Resultado += [PSCustomObject]@{
                Tipo = $o.Tipo; Nome = $o.DisplayName; AppId = $o.AppId
                Credencial = "Client secret"; KeyId = $c.KeyId
                Inicio = $c.StartDateTime; Expira = $c.EndDateTime
            }
        }
    }
    foreach ($k in $o.KeyCredentials) {
        if ($k.StartDateTime -ge $Desde) {
            $Resultado += [PSCustomObject]@{
                Tipo = $o.Tipo; Nome = $o.DisplayName; AppId = $o.AppId
                Credencial = "Certificado"; KeyId = $k.KeyId
                Inicio = $k.StartDateTime; Expira = $k.EndDateTime
            }
        }
    }
}

$Resultado | Sort-Object Inicio | Format-Table -AutoSize
$Resultado | Export-Csv ".\credenciais_desde_13out.csv" -NoTypeInformation -Encoding UTF8

# Para remover um segredo nao reconhecido em um app registration (revise antes!):
# Remove-MgApplicationPassword -ApplicationId <ObjectId-do-app> -KeyId <KeyId>

3. Revisar service principals com funções de diretório

Connect-MgGraph -Scopes "RoleManagement.Read.Directory","Directory.Read.All"

Get-MgDirectoryRole -All | ForEach-Object {
    $role = $_
    Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id -All |
        Where-Object { $_.AdditionalProperties.'@odata.type' -eq '#microsoft.graph.servicePrincipal' } |
        ForEach-Object {
            [PSCustomObject]@{
                Funcao = $role.DisplayName
                ServicePrincipal = $_.AdditionalProperties.displayName
                AppId = $_.AdditionalProperties.appId
            }
        }
} | Sort-Object Funcao | Format-Table -AutoSize

Qualquer aplicativo ConnectWise ou SkyKick com Global Administrator, Privileged Authentication Administrator ou Exchange Administrator que não tenha sido concedido intencionalmente deve ter a função removida após a desabilitação.

4. Exportar logins de service principal do aplicativo

Tenants com Entra ID Free têm apenas sete dias de retenção de logs. Exporte agora, antes que a janela de 13 a 16 de outubro se perca.

Connect-MgGraph -Scopes "AuditLog.Read.All"
$AppId = "506e08f9-6e9a-4da4-942b-a099a03644ae"
$Uri = "https://graph.microsoft.com/beta/auditLogs/signIns?`$filter=" +
       "signInEventTypes/any(t:t eq 'servicePrincipal') and appId eq '$AppId' " +
       "and createdDateTime ge 2026-10-13T00:00:00Z"

$Logins = @()
do {
    $Resp = Invoke-MgGraphRequest -Method GET -Uri $Uri -OutputType PSObject
    $Logins += $Resp.value
    $Uri = $Resp.'@odata.nextLink'
} while ($Uri)

$Logins | Select-Object createdDateTime, servicePrincipalName, ipAddress,
          resourceDisplayName, clientCredentialType,
          @{n="Status";e={$_.status.errorCode}} |
    Where-Object { $_.ipAddress -notlike "fd*" } |
    Export-Csv ".\sp_signins_cloudbackup.csv" -NoTypeInformation -Encoding UTF8

5. Endurecimento estrutural

Passada a contenção imediata, nós recomendamos medidas que reduzem o impacto de qualquer credencial de aplicação roubada no futuro:

• Ativar os Microsoft Graph activity logs (Entra ID P1 ou P2). Sem eles, não há IP de origem por requisição e é impossível separar uso legítimo de uso malicioso da mesma identidade. A coleta não é retroativa.
• Políticas de gestão de aplicativos para restringir ou bloquear client secrets em app registrations e limitar o tempo de vida de credenciais.
• Reduzir quem detém as funções Application Administrator e Cloud Application Administrator.
• Ativar App Instance Property Lock nos aplicativos próprios, medida que a Huntress aplicou após o incidente.
• Revisar exclusões de Acesso Condicional que beneficiem esses aplicativos.
• Microsoft Entra ID Protection para sinalizar service principals de risco.
• Inventário periódico de consentimentos de aplicativos multilocatários, removendo o que não é usado e reduzindo escopos excessivos.
• Manter os apps desabilitados até que a ConnectWise confirme a rotação de todas as credenciais.

Lições para MSPs e equipes de segurança

A Dolutech enxerga neste caso três lições estruturais.

A primeira é que identidades de aplicação não são cidadãs de segunda classe. Durante anos, o foco esteve em MFA, senhas e sessões de usuários. Um service principal com Directory.ReadWrite.All e acesso completo a e-mails é, na prática, uma conta de administrador sem MFA, sem dispositivo e sem horário de expediente.

A segunda é o efeito composto em ambientes de MSP. Um MSP usa aplicativos de gestão e acesso delegado para administrar muitos tenants. Uma cabeça de ponte em um único tenant de MSP pode virar caminho para todos os seus clientes. A Huntress não observou isso acontecendo neste caso, mas foi exatamente por esse risco que recomendou priorizar a revisão das ferramentas de gestão e segurança.

A terceira é a assimetria de visibilidade. Leituras via Graph não auditadas, ausência de IP de origem em ações app-only e retenção curta de logs em licenças básicas significam que muitas organizações simplesmente não conseguirão provar se houve ou não acesso aos dados. Agir antes de ter prova, neste contexto, não é exagero: é a única postura defensável.

Conformidade regulatória: NIS2, DORA, GDPR e LGPD

Mesmo sem confirmação de exfiltração, o acesso não autorizado a tenants com permissões de leitura e escrita sobre e-mails, arquivos e diretório configura incidente de segurança relevante em praticamente todos os enquadramentos regulatórios. A análise deve ser feita caso a caso, com apoio jurídico.

União Europeia e Portugal

• NIS2 (Diretiva (UE) 2022/2555): entidades essenciais e importantes devem avaliar se o incidente é significativo. Em caso positivo, o artigo 23 exige alerta precoce em até 24 horas, notificação em até 72 horas e relatório final em até um mês. O artigo 21 inclui expressamente a segurança da cadeia de abastecimento e da relação com fornecedores entre as medidas obrigatórias de gestão de risco. Em Portugal, o ponto de contato é o CNCS, com o CERT.PT como equipe nacional de resposta a incidentes.
• DORA (Regulamento (UE) 2022/2554): entidades financeiras devem tratar o caso dentro do quadro de gestão do risco de terceiros de TIC, avaliar a classificação como incidente grave e atualizar o registro de informações sobre prestadores. O episódio é um exemplo claro do risco de concentração em fornecedores de TIC que o regulamento procura endereçar.
• GDPR (Regulamento (UE) 2016/679): se houver risco para os direitos dos titulares, o responsável pelo tratamento deve notificar a autoridade de controle em até 72 horas (artigo 33), que em Portugal é a CNPD, e avaliar a comunicação aos titulares (artigo 34). MSPs atuam tipicamente como subcontratantes e têm o dever de informar o responsável sem demora injustificada (artigos 28 e 33, n.º 2).

Brasil

• LGPD (Lei 13.709/2018): o artigo 48 obriga o controlador a comunicar à ANPD e aos titulares a ocorrência de incidente que possa acarretar risco ou dano relevante. O Regulamento de Comunicação de Incidente de Segurança (Resolução CD/ANPD nº 15/2024) estabelece prazo de três dias úteis a partir do conhecimento do incidente. O operador, como o MSP, deve informar o controlador para que este cumpra sua obrigação. Organizações devem registrar o incidente e documentar as medidas de contenção, mesmo quando concluírem que não há risco relevante.

Em todos os cenários, a documentação gerada pelos scripts deste artigo (exportações de logins, credenciais e funções) é evidência valiosa para demonstrar diligência perante reguladores.

Conclusão

O incidente do ConnectWise Cloud Backup mostra, de forma quase didática, como a confiança concedida a um fornecedor pode ser convertida em acesso massivo sem que nenhum controle centrado no usuário seja acionado. Um segredo vazado, um aplicativo multilocatário com permissões amplas e um script percorrendo uma lista ordenada foram suficientes para alcançar 173 tenants confirmados em poucas horas.

Aqui no Blog Dolutech, a nossa recomendação é objetiva: desabilite agora os aplicativos ConnectWise e SkyKick, audite todas as credenciais de aplicativos criadas desde 13 de outubro, revise funções de diretório atribuídas a service principals, exporte os logs antes que expirem e só reative o serviço após confirmação formal de rotação de credenciais pela ConnectWise. Em seguida, trate a governança de identidades de aplicação com o mesmo rigor que já aplica às identidades humanas.

Continuaremos acompanhando a investigação e atualizaremos este conteúdo assim que houver novidades sobre causa raiz, atribuição ou impacto confirmado.

Lucas Catão de Moraes

Amante por tecnologia Especialista em Cibersegurança e Big Data, Formado em Administração de Infraestrutura de Redes, Pós-Graduado em Ciências de Dados e Big Data Analytics e Machine Learning, Com MBA em Segurança da Informação, Escritor do livro ” Cibersegurança: Protegendo a sua Reputação Digital”.