Abuso de SaaS e Aplicações Corporativas

Nota 08 do capítulo 26 (CTI e Threat Hunting em Ambientes Modernos), fechando o bloco com a superfície SaaS e as aplicações corporativas onde o dado da organização realmente mora.
A nota cobre concessões OAuth maliciosas, compartilhamento público acidental, exfiltração por download e shadow SaaS, com telemetria de audit logs e caça de abuso por plataforma.
Dialoga com a nota 11 do capítulo 08 (Hunting em Cloud e SaaS), com a nota 05 deste capítulo em telemetria e com os controles DAT.4 e PRT.4 do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

O SaaS inverteu a premissa operacional da segurança corporativa: o dado sensível não está mais atrás do perímetro da organização, e sim distribuído em dezenas de plataformas de terceiros, acessadas por identidades federadas e compartilhadas com parceiros, clientes e aplicativos de conveniência. O adversário não precisa quebrar nada para entrar, porque credencial comprada ou sessão roubada concede acesso ao mesmo inbox, drive ou pipeline de vendas que o funcionário usa, e o abuso costuma se disfarçar de comportamento legítimo de trabalho. Esta nota organiza a defesa dessa superfície em quatro vetores de abuso, na telemetria disponível por plataforma e nas caças que detectam cada padrão.

O posicionamento na biblioteca fecha o arco do capítulo 26: a nota 05 entregou a telemetria de cloud que hospeda tudo isso, a nota 06 cobriu o runtime das aplicações, a nota 07 cobriu a esteira que as fabrica, e aqui resta o plano de aplicação corporativa, onde o usuário é o agente da ação e o audit log do SaaS é a única testemunha. A nota 11 do capítulo 08 já mapeou as técnicas ATT&CK do domínio cloud e SaaS, e esta nota aprofunda a parte de aplicação corporativa com o detalhe operacional por plataforma.

2. SaaS como Superfície Corporativa Primária

As plataformas que concentram o dado corporativo formam um conjunto conhecido, e cada uma tem um perfil de risco dominante que orienta a prioridade de telemetria. A lista abaixo resume as cinco mais comuns e o que o adversário busca em cada uma.

• Microsoft 365: concentra e-mail, arquivos, chat e identidade da maioria das organizações, e por isso é o alvo padrão de BEC, de acesso após phishing e de exfiltração por download de SharePoint e OneDrive. O Unified Audit Log é a fonte central que registra quase tudo o que importa.
• Google Workspace: espelha o mesmo papel em organizações de cultura Google, com o risco adicional do modelo de compartilhamento de Drive, onde o link com permissão ampla substitui o anexo e facilita o vazamento silencioso.
• Slack e mensageiros corporativos: concentram fragmentos de segredo compartilhado por conveniência, integrações de entrada via webhooks e apps de terceiros com escopo de leitura de canais, e são vetor de exfiltração de informação em formato de conversa, que raramente entra no escopo do DLP tradicional.
• Notion, Confluence e wikis: hospedam a documentação de processos, arquiteturas e credenciais anotadas por pressa, e o compartilhamento público acidental de página nessas ferramentas é achado recorrente de EASM.
• Salesforce e CRMs: carregam a base de clientes, oportunidades e, em alguns fluxos, dados pessoais sensíveis, e o abuso típico é a exportação de relatórios e a consulta massiva via API por conta legítima comprometida.
• Plataformas de RH e ERP em SaaS: concentram folha, dados pessoais de colaboradores e fluxos de pagamento, e o comprometimento dessas plataformas já apareceu em campanhas de fraude fiscal e de engenharia social de transferência, no padrão atribuído a operações de estilo FAMOUS CHOLLIMA.

A característica que atravessa todas elas é que a ação do adversário é indistinguível do trabalho legítimo no plano técnico: abrir e-mail, baixar arquivo, autorizar aplicativo e compartilhar página são operações normais. A detecção, portanto, não vem do evento, e sim do desvio de baseline: volume, horário, padrão de acesso por identidade e coerência entre o papel da pessoa e o que ela tocou.

O plano unificador dessa superfície é a identidade federada: o mesmo principal que acessa o drive, o chat, o CRM e o wiki atravessa plataformas com sessões e tokens derivados de uma única autenticação corporativa. Essa concentração explica por que o comprometimento de identidade é a porta de entrada dominante do abuso de SaaS, e por que a caça nesta nota é sempre acompanhada da caça de autenticação do provedor de identidade, tema da nota 10 do capítulo 08.

3. Vetores de Abuso e TTPs Correspondentes

Os quatro vetores dominantes de abuso em SaaS têm assinaturas distintas e dependências de telemetria diferentes, e a tabela abaixo os consolida com o mapeamento ATT&CK e o sinal característico de cada um.

Sobre o mapeamento, vale a precisão: o compartilhamento público acidental é coleta de dado em repositório de informação (T1213), com a exfiltração acontecendo em etapa posterior, quando o terceiro acessa o link, e a exfiltração por download combina T1005 na coleta direta com T1567.002 na saída para armazenamento do adversário. O hunting que encadeia as duas etapas, coleta e saída, constrói a narrativa que o alerta isolado nunca entrega.

O OAuth grant malicioso merece destaque porque é o vetor com melhor relação esforço-impacto disponível no momento: a página de consentimento legítima do provedor, apresentada após phishing convencional, transforma o adversário em aplicativo com acesso contínuo à caixa postal ou ao drive, independente de MFA e de troca de senha. Incidentes públicos com ferramentas de phishing de token de device code e consentimento mostram o padrão, e a defesa é telemetria de consentimento com bloqueio de apps não verificados, porque a detecção posterior por comportamento já encontra o adversário instalado.

O shadow SaaS, por sua vez, é o vetor silencioso: contas corporativas registradas em serviços não catalogados criam identidades fora da governança, e o comprometimento dessas contas, muitas vezes reutilizando senha corporativa, volta para o ambiente principal via reutilização de credencial. O hunting de shadow SaaS combina egress DNS e HTTP com fluxos de cadastro que revelam domínios de serviço novos consumidos por identidades corporativas.

O padrão de abuso mais frequente na prática operacional, no entanto, é o BEC (Business Email Compromise): o adversário entra na caixa postal com credencial ou sessão roubada, instala regra de inbox para esconder respostas do remetente legítimo, monitora conversas financeiras e só então age, cobrando em conta nova ou redirecionando pagamento. Atuações de grupos como FIN11 e os casos recentes atribuídos a operações de extorsão de help desk, no estilo Scattered Spider, mostram a progressão de phishing para abuso persistente de SaaS, e a assinatura técnica dessa progressão, regra de inbox nova mais acesso silencioso a mensagens, é caçável com a mesma telemetria do download em massa.

4. Telemetria de SaaS e Ferramentas de Visibilidade

A fonte primária em cada plataforma é o audit log nativo, e a disciplina de ingestão é a mesma da nota 05: tudo para o SIEM, com retenção que sustente janela de campanha. No Microsoft 365, o Unified Audit Log concentra os eventos de SharePoint e OneDrive (FileDownloaded, FileUploaded, SharingOperation), do Exchange (MailItemsAccessed, SearchQueryInitiated, criação de inbox rule) e do Entra (Consent to application, Add app role assignment grant to user), com o Defender for Cloud Apps agregando via CloudAppEvents a visão de aplicativos conectados. No Google Workspace, os Admin Reports cobrem login, Drive, token authorization e administração, com exportação para BigQuery ou SIEM. No Salesforce, o par SetupAuditTrail e LoginHistory mais os eventos em tempo real da plataforma cobrem administração, autenticação e acesso à API. No Slack, a audit API registra acesso, mudanças de canal e apps instalados; no Notion, o audit log da edição Enterprise registra membros, compartilhamento e exportação.

A camada de ferramentas complementa a telemetria nativa com normalização e contexto: plataformas de SSPM (SaaS Security Posture Management), como Adaptive Shield e DoControl, mapeiam configurações de compartilhamento, apps OAuth instalados e desvios de política; soluções CASB, como o Defender for Cloud Apps, agregam sessão e descoberta; e o CSPM SaaS do capítulo 21 cobre a face exposta de fora. A regra de ouro é que a telemetria nativa no SIEM responde a pergunta investigativa, e a ferramenta de SSPM responde a pergunta de exposição, e as duas não se substituem.

A retenção merece atenção específica porque varia por plano, por serviço e por licença, e o janelamento de caça precisa ser calculado com a retenção real de cada fonte, e não com a telemetria ideal. Serviços de auditoria avançada cobrem eventos de alto valor, como MailItemsAccessed, que o plano básico não registra, e o inventário de dados do TH.1 deve registrar explicitamente quais eventos da tabela acima estão efetivamente disponíveis, porque caça que assume evento inexistente produz lacuna silenciosa.

5. Hunting de Abuso em SaaS

As heurísticas de caça em SaaS seguem o formato padrão da biblioteca, com hipótese declarada antes da consulta, e as quatro abaixo cobrem os vetores da seção 3. Para cada uma, o baseline por identidade e por unidade de negócio é o que separa sinal de ruído, e a nota 04 do capítulo 02 fundamenta a avaliação dessas fontes.

A verificação de cada candidata repete o ritual das notas anteriores: confirmar a identidade e o IP no plano de autenticação da plataforma, verificar a coerência entre papel e ação, procurar a justificativa operacional e só então classificar como incidente, baseline documentado ou falso positivo construtivo. O output da caça alimenta o PIR do capítulo 05 quando o padrão indica campanha externa, e alimenta o ajuste de política do SaaS quando o padrão é interno.

A cadência dessas caças merece decisão explícita: as de consentimento e de compartilhamento público se prestam a execução contínua ou diária, por afetarem superfície de exposição, enquanto as de volume, como download em massa e exportação de CRM, ganham com janela semanal e agregação por baseline mais longo. O capítulo 07 fornece o formato de documentação, e a nota 06 do mesmo capítulo trata da automatização dessas rotinas quando o limiar e o baseline amadurecem.

6. Exemplo de Caça: Download em Massa no M365

A caça de download em massa no SharePoint e no OneDrive é implementada no KQL do Sentinel sobre a tabela OfficeActivity, agregando por identidade e por dia os eventos de FileDownloaded e contando arquivos, sites e endereços de origem distintos. O limiar de arquivos por dia é ajustado ao baseline da organização, e a presença de múltiplos sites ou de user agent de sincronização atípico eleva a prioridade.

// Download em massa de SharePoint e OneDrive por identidade e dia
OfficeActivity
| where TimeGenerated > ago(7d)
| where RecordType =~ "SharePointFileOperation" and Operation =~ "FileDownloaded"
| summarize Downloads = count(),
    Arquivos = dcount(SourceFileName),
    Sites = dcount(Site_Url),
    IPs = dcount(IPAddress),
    Agentes = make_set(UserAgent)
    by UserId, bin(TimeGenerated, 1d)
| where Arquivos > 200 or Sites > 3
| order by Arquivos desc, Sites desc

A segunda etapa cruza as candidatas com o plano de autenticação, verificando no SigninLogs se a mesma identidade apresenta login de risco, país novo ou sessão de protocolo legado na mesma janela, e com o plano de e-mail, verificando MailItemsAccessed em volume, que é o paralelo do download na caixa postal. O padrão de exfiltração por insider, por sua vez, aparece sem login anômalo, e é aí que a coerência entre papel e volume decide: vendedor que baixa duzentos arquivos é rotina, analista financeiro que baixa arquivos de três sites de RH no domingo é hipótese de incidente.

O desfecho da caça segue o caminho das notas anteriores: o padrão confirmado vira caso no IR.2 do capítulo 15 com prioridade definida pelo dado acessado, o padrão explicado vira baseline documentado e exclusão justificada, e a recorrente ausência de telemetria de download em algum tenant satélite vira item de backlog para o DAT.1. A promoção a detecção permanente usa a ponte do capítulo 18, com a regra nascendo da versão final da consulta e o limiar evoluindo com o histórico de falsos positivos.

A caça de consentimento OAuth complementa o quadro e responde ao vetor de melhor relação esforço-impacto da seção 3. A consulta abaixo extrai os consentimentos recentes no Entra e filtra os escopos que concedem leitura e escrita de correio e de arquivos, que são os que sustentam acesso persistente ao dado corporativo.

// Consentimentos de aplicativo com escopo perigoso nos ultimos 30 dias
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName =~ "Consent to application"
| extend App = tostring(TargetResources[0].displayName),
         Escopo = tostring(parse_json(tostring(TargetResources[0].modifiedProperties[0].newValue)))
| where Escopo has_any ("Mail.ReadWrite", "Mail.Send", "Files.ReadWrite.All", "Sites.Read.All", "full_access_as_app")
| project TimeGenerated, App, Escopo,
    ConcedidoPor = tostring(InitiatedBy.user.userPrincipalName),
    IP = tostring(InitiatedBy.user.ipAddress)
| order by TimeGenerated desc

A leitura dos resultados compara cada app concedido com o inventário de aplicativos autorizados mantido pelo SSPM, verifica se o publisher é verificado e checa a reputação do identificador do app nas fontes de inteligência. Consentimento para app não verificado com escopo de correio, concedido fora do horário comercial e sem ticket associado, é o tripé que caracteriza o consent phishing, e o desfecho imediato é revogação do app, invalidação de refresh tokens da identidade e revisão das pastas acessadas no período.

O mesmo desenho de caça funciona no Google Workspace com o Admin Report do Drive, e a variação é apenas a fonte: sobre o export JSON do relatório, o comando abaixo extrai os eventos de download por identidade, mantendo a lógica de agregação por volume.

# Downloads agregados a partir do export JSON do Admin Report do Drive
jq -r '.events[] | select(.name == "download")
       | [.id.time, .actor.email, .parameters[0].value]
       | @tsv' drive_audit.json \
  | sort | uniq -c | sort -rn | head -20

A variação de provedor não muda o desenho da caça, e esse é o aprendizado mais importante da seção: a hipótese, o limiar e o ritual de verificação são independentes de plataforma, mudando apenas o nome do evento e o campo de identidade. Times que mantêm a biblioteca de caças organizada por hipótese, e não por provedor, cobrem um SaaS novo em horas, e é essa reutilização que o capítulo 07 formaliza como caça repetível e automatizável.

7. Erros Comuns e Pontos de Atenção

• Confiar no limiar fixo de volume: duzentos arquivos podem ser rotina de um time e exfiltração de outro, e o limiar que não é calibrado por perfil de função gera tanto ruído quanto cegueira.
• Tratar o consentimento OAuth como evento de baixa prioridade: a concessão sobrevive a troca de senha e a reset de MFA, e a única remoção confiável é a revogação do app com revisão de escopo, o que a torna alerta de alta prioridade por definição.
• Olhar apenas o download e ignorar o acesso: MailItemsAccessed e equivalente de leitura em Drive capturam o adversário que fotografa tela ou exporta em silêncio, e a ausência de evento de download não é prova de ausência de exfiltração.
• Descartar o audit log por retenção curta: a retenção padrão de alguns planos SaaS é de meses ou semanas, e a ingestão atrasada para o SIEM significa campanha que nunca será reconstruída.
• Deixar o shadow SaaS fora do inventário: a caça em plataformas catalogadas não enxerga a conta corporativa comprometida em serviço não catalogado, e o EASM e o DNS corporativo são as fontes que fecham esse buraco.
• Tratar cada plataforma como ilha: o adversário atravessa plataformas com a mesma identidade federada, e a caça que não correlaciona Entra, M365 e terceiros perde a narrativa que diferencia uso de abuso.
• Repassar o alerta de download sem o plano de autenticação: download anômalo com login limpo é o padrão de sessão roubada, e o alerta isolado descreve metade do incidente; a junção com SigninLogs é parte da caça, e não etapa opcional.
• Ignorar integrações e webhooks de entrada: apps de terceiros instalados em Slack, Notion e CRM executam com credencial própria e fora da sessão do usuário, e o inventário de integrações é superfície de hunting tão importante quanto o inventário de usuários.

O ponto de atenção final é a governança de identidade como pré-requisito: nenhuma consulta desta nota funciona bem sobre um ambiente sem inventário confiável de identidades, papéis e apps autorizados. O hunting de SaaS é, antes de tudo, hunting sobre um mapa de quem pode fazer o quê, e a ausência desse mapa transforma qualquer resultado em ambiguidade.

8. Integração com o Restante da Biblioteca

No capítulo 26, esta nota completa o quadro iniciado pela telemetria de cloud da nota 05 e pelo runtime da nota 06, e se conecta diretamente à esteira da nota 07, porque o GitHub e o Slack corporativos são simultaneamente SaaS e infraestrutura da cadeia de software. A nota 11 do capítulo 08 fornece as técnicas ATT&CK do domínio, e o controle PRT.4 recebe daqui a extensão de monitoramento de aplicação corporativa.

No plano transversal, o capítulo 21 apoia o hunting de shadow SaaS e de exposição externa com EASM e CTEM, o capítulo 10 fornece o loop de feedback que transforma achados recorrentes em requisitos de inteligência, e o capítulo 11 formaliza as métricas de cobertura e de latência de detecção dessa superfície. O capítulo 12, nas notas de qualidade de dados e de privacidade, delimita o que pode ser coletado e por quanto tempo, lembrando que a telemetria de SaaS trata do trabalho das pessoas, e a linha entre visibilidade e vigilância é decisão de governança, e não de engenharia. A nota 02 do capítulo 13 fecha o ciclo com a contraparte ofensiva dessa superfície, porque saber como o adversário abusa de OAuth e de compartilhamento é o que orienta a coleta de contra-inteligência sobre a própria organização.