O Copilot quebrou sua detecção de ameaças internas, e o MITRE escreveu a prova

A MITRE ATT&CK publica uma analítica de detecção, AN1380, para adversários que fazem mining no SharePoint em busca de documentos internos úteis. Ela diz:

"Contas privilegiadas ou raramente usadas realizando acesso em massa a arquivos ou metadados do SharePoint em uma janela curta de tempo, indicando uma possível coleta com script de documentos internos sensíveis."

Isso também é o que o Microsoft 365 Copilot faz quando alguém pede a ele que resuma as negociações contratuais do trimestre passado.

Mesmo comportamento, mesma telemetria. Um é a técnica T1213.002, dados de repositórios de informação: SharePoint. O outro é um funcionário licenciado fazendo seu trabalho.

Nenhuma violação necessária

Toda técnica no ATT&CK presume um adversário que precisou entrar em algum lugar primeiro. HAFNIUM, Ke3chang e Chimera são grupos de espionagem patrocinados por estados que o MITRE rastreia pelo nome, e os três aparecem nos exemplos de procedimento dessa técnica. O HAFNIUM abusou de credenciais comprometidas para exfiltrar dados do SharePoint. O Ke3chang executou uma ferramenta de enumeração feita sob medida chamada spwebmember. O Chimera coletou documentos depois de estabelecer acesso. Cada um deles precisou de uma forma de entrar.

O Copilot não precisa de nada disso. Sem CVE, sem token roubado, sem ferramenta em um host, sem violação de política. Ninguém na cadeia pretende causar dano, e o consentimento foi concedido anos atrás por quem configurou a herança em um site que já não tem mais dono.

Uma técnica criada em fevereiro de 2020 não mudou. O que mudou foi o denominador. O acesso em massa a um repositório costumava implicar um script, e um script costumava implicar alguém que não deveria estar ali. Agora todo usuário licenciado produz esse mesmo padrão várias vezes ao dia, apenas digitando uma pergunta em inglês.

O reconhecimento do Scattered Spider agora é um prompt

O MITRE registra que, durante a campanha C0027, o Scattered Spider acessou ambientes SharePoint das vítimas "para buscar informações de inscrição de VPN e MFA, instruções da central de suporte e guias para novos funcionários." Esse reconhecimento é o trabalho preparatório antes de uma ligação de engenharia social para a central de suporte.

Chegar a essa informação costumava exigir que um invasor violasse a rede. Agora está disponível para qualquer pessoa que consiga se autenticar como funcionário e fazer a pergunta: "qual é o nosso processo quando alguém precisa reinscrever o MFA?"

A versão da intrusão deixava rastros como arquivos acessados, sistemas sondados e artefatos no disco. A versão de IA deixa uma pergunta que qualquer novo funcionário poderia fazer.

Existem duas opções, e a maioria das equipes já escolheu uma por acidente

O uso de IA é tão predominante que as equipes de TI ou SecOps ficariam sobrecarregadas por alertas sobre prompts que poderiam ser reconhecimento. Isso deixa duas más opções:

Reajustar a detecção. Elevar o limite, ou excluir o service principal do agente. A cobertura para T1213.002 vai silenciosamente a zero, e a técnica continua funcionando tão bem quanto sempre funcionou.

Ou deixar como está. Os analistas fazem triagem de atividade de IA o dia todo, a fadiga de alertas faz o que a fadiga de alertas faz, e a detecção morre de qualquer forma.

A maioria das organizações escolheu a primeira opção sem realmente decidir isso. Alguém silenciou o ruído durante uma semana corrida e nada ficou registrado. Audite hoje sua cobertura em relação ao ATT&CK, e é provável que essa célula ainda esteja verde.

A lacuna de atribuição aparece seis meses depois, em um caso de RH

O log de auditoria diz que a conta de um usuário acessou o modelo de remuneração. O usuário diz que nunca abriu esse arquivo. As duas coisas podem ser verdadeiras. O agente exibiu duas linhas dele dentro de um resumo de outra coisa.

Agora investigue isso. A intenção é o que separa uma ameaça interna de um acidente, e a intenção é justamente o que o log não consegue mais estabelecer. A análise comportamental torna isso mais difícil, porque essas linhas de base presumem um ritmo humano, e a mesma conta agora emite rajadas em velocidade de máquina. O normal se amplia para todos, o que deixa mais espaço para que um comportamento humano anômalo passe despercebido.

Você provavelmente já implantou o Copilot, então comece pelo que ele já alcançou

A maioria das orientações existentes presume que você ainda não o ativou. Aqui estão três perguntas a fazer depois que já o tiver ativado:

A que as identidades conseguem realmente acessar agora? Não as permissões no papel, mas o caminho efetivo: grupos aninhados, permissões de site herdadas, links de compartilhamento que sobreviveram aos seus projetos, contas de convidado que ninguém revisou desde o onboarding.

O que a atividade orientada por IA tocou nos últimos 90 dias? Você precisa do registro antes de precisar da política.

Quais detecções ainda tratam o acesso em massa a repositórios como evidência de um adversário? Encontre-as, e desta vez decida deliberadamente.

O Netwrix 1Secure cobre as duas primeiras. Ele descobre e classifica dados sensíveis em repositórios na nuvem e on-premises, mapeia quais identidades conseguem acessá-los e por quais caminhos, e monitora o acesso orientado por IA em relação a esse panorama. A terceira pergunta não tem uma resposta defensável até que você consiga responder às duas primeiras.

O Copilot não é o problema. Ele está fazendo exatamente o que a Microsoft disse que faria, com as permissões que sua organização aprovou. O problema é que sua lógica de detecção codifica a suposição de que esse padrão significa um adversário, uma suposição que silenciosamente deixou de ser verdadeira, e ninguém soube que devia abrir um chamado para revisá-la.