Cibersegurança e segurança da informação

Investigação de Conta Suspeita do Microsoft 365: Entra, Mailbox e Defender

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre investigação de contas Microsoft 365 na área de Cloud Security e IR

Resposta rápida

A investigação de uma conta do Microsoft 365 requer a conexão de Identidade, Registos de Auditoria, ações de API, recursos, Regiões e Sessões. Começa-se com a preservação das evidências e a construção de uma linha do tempo, e só depois se procede ao confinamento documentado.

A investigação na nuvem exige a conexão de identidades, Control Plane, recursos, chaves, sessões e serviços de segurança. Uma vez que a atividade está dispersa por serviços e regiões, a linha do tempo e a compreensão das permissões são cruciais. Este artigo foca-se na investigação de uma conta Microsoft 365 e destina-se a analistas SOC e investigadores de Cloud. O objetivo é fornecer uma metodologia de trabalho que possa ser aplicada na prática, numa entrevista profissional e num ambiente de trabalho, sem se contentar com uma definição de dicionário.

O principal desafio é que os dados são quase sempre parciais. SigninLogs, AuditLogs, OfficeActivity podem apontar numa direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Por isso, construiremos a investigação em torno de uma questão de investigação, evidências necessárias e um critério claro para a conclusão.

O cenário prático no artigo é: Linha do tempo de uma conta de nuvem simulada. Todos os exemplos são dados de laboratório ou descrições de processos. Quando se trata de Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com autorização explícita, um Scope definido e a capacidade de parar o teste.

Verificação do Incidente

Uma investigação profissional de uma conta Microsoft 365 começa com condições de sucesso e condições de falha. Define-se um caso positivo, um caso negativo, um caso limite e uma atividade legítima semelhante. Desta forma, é possível identificar tanto falsos negativos quanto falsos positivos.

Num ambiente autorizado, utiliza-se a ação mínima que prova a alegação sem causar danos. Preservam-se a entrada, a saída, o tempo e a versão, e após a correção, realiza-se um Retest no mesmo cenário e verifica-se também a regressão em funções próximas.

Entra sign-ins e Risco

O tópico 'Entra sign-ins e Risco' é uma parte central do trabalho na investigação de uma conta Microsoft 365. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático da ferramenta sem compreender o objetivo.

Na prática, registe os SigninLogs, AuditLogs, OfficeActivity, regras da caixa de entrada, consentimento OAuth, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Mailbox e Auditoria

O tópico 'Mailbox e Auditoria' é uma parte central do trabalho na investigação de uma conta Microsoft 365. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático da ferramenta sem compreender o objetivo.

OAuth, Sessões e Endpoints

Na investigação de uma conta Microsoft 365, identidade e autorização são duas questões distintas: quem é o cliente e o que lhe é permitido fazer no recurso. Verificam-se Roles, Claims, Session, Object ownership e alterações ao longo do ciclo de vida, não se contentando com o facto de o utilizador estar 'conectado'.

A matriz de teste inclui um utilizador anónimo, um utilizador normal, o proprietário do objeto, outro utilizador e um administrador. Para cada ação, compara-se a Response e o impacto do lado do servidor. A alteração de um identificador ou cabeçalho é apenas um meio de teste; a evidência é que o servidor aprovou ou recusou uma ação em oposição à política.

Confinamento e Recuperação

A resposta à investigação de uma conta Microsoft 365 deve reduzir o risco sem apagar as evidências que ainda são necessárias. Começa-se com uma ação reversível e focada, confirmam-se a propriedade e a autoridade, e documentam-se o tempo, a execução e o resultado.

A correção a longo prazo aborda a raiz: permissões, configuração, Validation, Telemetry, processo ou formação. Após a implementação, realiza-se um Retest e monitorizam-se os sinais de recorrência, em vez de se contentar com o fecho do Ticket.

Focos de Teste Exclusivos

Neste tópico, recomenda-se construir antecipadamente um mapa de evidências focado. Os principais focos de teste são: SigninLogs, AuditLogs, OfficeActivity, inbox rules, OAuth consent, session revocation. A lista não é uma Checklist automática; cada item é selecionado porque pode ligar uma entidade, uma ação e um tempo ou explicar um comportamento legítimo.

SigninLogs: Defina qual é o valor esperado, o que será considerado excecional e qual fonte adicional irá verificar a descoberta.
AuditLogs: Defina qual é o valor esperado, o que será considerado excecional e qual fonte adicional irá verificar a descoberta.
OfficeActivity: Defina qual é o valor esperado, o que será considerado excecional e qual fonte adicional irá verificar a descoberta.
inbox rules: Defina qual é o valor esperado, o que será considerado excecional e qual fonte adicional irá verificar a descoberta.
OAuth consent: Defina qual é o valor esperado, o que será considerado excecional e qual fonte adicional irá verificar a descoberta.
session revocation: Defina qual é o valor esperado, o que será considerado excecional e qual fonte adicional irá verificar a descoberta.

Quando um dos focos não está disponível, deve-se documentar a lacuna e escolher uma alternativa. Por exemplo, se o identificador do Process não for estável, pode-se usar o tempo, Host, User e Parent; se o Payload estiver encriptado, usam-se Metadata, volume, frequência e o contexto TLS/DNS.

Processo de Trabalho Recomendado

Defina o Scope e uma questão de trabalho sobre a investigação da conta Microsoft 365.
Registe as fontes de dados e as evidências necessárias: SigninLogs, AuditLogs, OfficeActivity, inbox rules.
Crie uma Baseline curta de comportamento normal ou resultado esperado.
Execute o teste mínimo em ambiente de laboratório e guarde o tempo, a entrada e a saída.
Crie uma Timeline ou tabela de comparação e separe facto de interpretação.
Realize um Pivot para uma fonte adicional para verificar ou refutar a explicação inicial.
Resuma a decisão, limitações, ação recomendada e critério de Retest.

Cenário Prático

O cenário selecionado é uma linha do tempo de uma conta de nuvem simulada. O objetivo do exercício não é provar a capacidade de ataque, mas praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, definem-se dados simulados, uma janela de tempo e um resultado esperado.

No final do exercício, um produto deve ser enviado para que outro analista ou testador possa criticar: uma captura de tela ou Export da evidência, uma breve Timeline, uma hipótese inicial, uma evidência de verificação, uma limitação e uma recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

Etapa	O que é realizado	Produto
Preparação	Defina o Scope, o tempo e o objetivo. Registe quais campos ou evidências de SigninLogs, AuditLogs, OfficeActivity devem aparecer.	Plano de teste curto
Criação de Dados	Realize uma ação segura e simulada relacionada à investigação da conta Microsoft 365, sem informações reais ou impacto no sistema de produção.	Evento/Requisição/Fluxo controlado
Recolha	Recolha a evidência bruta e o contexto de uma fonte adicional. Verifique o Time zone, os identificadores e a integridade.	Duas evidências relacionadas
Análise	Escreva o que cada evidência prova, o que não prova e qual é a explicação legítima possível.	Conclusão provisória
Conclusão	Escolha fecho, escalada, Finding ou Tuning; adicione recomendação e Retest.	Produto documentado

Checklist Prática

Verifique e documente: Principal e session.
Verifique e documente: API action.
Verifique e documente: Resource e region.
Verifique e documente: Source IP e user agent.
Verifique e documente: Audit event ID.
Verifique e documente: GuardDuty/Defender/SCC finding.
Indique o Time zone, a versão da ferramenta e a hora da recolha.
Guarde os dados brutos antes de filtrar ou alterar.
Escreva o que a descoberta prova e o que ainda é desconhecido.
Defina o proprietário e a ação de acompanhamento com uma data.

Erros Comuns

Focar-se apenas numa área.
Rodar uma chave antes de preservar a Timeline.
Não verificar AssumeRole ou Token.
Ignorar o Control Plane.
Não mapear permissões eficazes.
Concluir que a localização geográfica prova um ataque.

Resumo e CTA

A investigação de uma conta Microsoft 365 suspeita: Entra, Mailbox e Defender é um tópico que liga o conhecimento técnico à disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, preserve o contexto e o tempo, e escolha uma ação que possa ser justificada e retestada.

No curso Cybersecurity & AI da HPI, estes princípios são praticados através de sistemas, logs e laboratórios. O próximo passo natural é passar aos artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portfólio profissional.

Perguntas frequentes

A investigação de uma conta Microsoft 365 por si só prova um ataque ou uma vulnerabilidade?

Não. Fornece um sinal ou uma descoberta que precisa de contexto, verificação e uma fonte adicional. Uma conclusão profissional baseia-se numa sequência de evidências e na sua conformidade com o comportamento esperado.

O que fazer quando alguns dos dados estão em falta?

Documente o que falta, verifique uma fonte alternativa e reduza o nível de confiança. Não preencha campos por suposição nem apresente 'Unknown' como correto.

Quanto tempo as evidências devem ser mantidas?

O tempo depende da política, regulamentação, custo e tipo de incidente. É importante definir antecipadamente a Retention, Legal hold e a capacidade de exportar evidências num formato que possa ser verificado.

Como praticar sem comprometer um sistema real?

Utilize máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, defina o Scope, Stop conditions e faça um backup antes de iniciar o trabalho.