Investigação de aplicações comprometidas e maliciosas
Este artigo fornece orientação sobre como identificar e investigar ataques mal-intencionados em um ou mais aplicativos em um locatário cliente. As instruções passo a passo ajudam você a tomar as medidas corretivas necessárias para proteger as informações e minimizar outros riscos.
- Pré-requisitos: Abrange os requisitos específicos que você precisa preencher antes de iniciar a investigação. Por exemplo, registro em log que deve ser ativado, funções e permissões necessárias, entre outros.
- Fluxo de trabalho: mostra o fluxo lógico que você deve seguir para executar esta investigação.
- Etapas da investigação: Inclui orientações detalhadas passo a passo para esta investigação específica.
- Etapas de contenção: contém etapas sobre como desativar os aplicativos comprometidos.
- Etapas de recuperação: contém etapas de alto nível sobre como recuperar/mitigar de um ataque mal-intencionado a aplicativos comprometidos.
- Referências: Contém outros materiais de leitura e referência.
Pré-requisitos
Antes de iniciar a investigação, certifique-se de que tem as ferramentas e permissões corretas para recolher informações detalhadas.
Para usar sinais de proteção de identidade, o locatário deve ser licenciado para o Microsoft Entra ID P2.
- Compreensão dos conceitos de risco da Proteção de Identidade
- Compreensão dos conceitos de investigação da Proteção de Identidade
Uma conta com, pelo menos, a função de Administrador de Segurança .
Capacidade de usar o Microsoft Graph Explorer e estar familiarizado (até certo ponto) com a API do Microsoft Graph.
Familiarize-se com os conceitos de auditoria de aplicativos (parte do https://aka.ms/AzureADSecOps).
Certifique-se de que todas as aplicações Enterprise no seu inquilino têm um proprietário definido para efeitos de responsabilização. Analise os conceitos de visão geral de proprietários de aplicativos e atribuição de proprietários de aplicativos.
Familiarize-se com os conceitos da investigação de concessão de Consentimento de Aplicativo (parte do https://aka.ms/IRPlaybooks).
Certifique-se de que compreende as seguintes permissões do Microsoft Entra:
Familiarize-se com os conceitos de deteções de risco de identidade de carga de trabalho.
Você deve ter uma licença completa do Microsoft 365 E5 para usar o Microsoft Defender for Cloud Apps.
- Compreender os conceitos de investigação de alerta de deteção de anomalias
Familiarize-se com as seguintes políticas de gerenciamento de aplicativos:
Familiarize-se com as seguintes políticas de governança de aplicativos:
Ferramentas necessárias
Para uma investigação eficaz, instale o seguinte módulo do PowerShell e o kit de ferramentas em sua máquina de investigação:
Fluxo de Trabalho
Passos de investigação
Para essa investigação, suponha que você tenha uma indicação de um possível comprometimento do aplicativo na forma de um relatório de usuário, exemplo de logs de entrada do Microsoft Entra ou uma deteção de proteção de identidade. Certifique-se de concluir e habilitar todas as etapas de pré-requisito necessárias.
Este manual é criado com a intenção de que nem todos os clientes da Microsoft e suas equipes de investigação tenham o pacote de licença completo do Microsoft 365 E5 ou Microsoft Entra ID P2 disponível ou configurado. Este manual destaca outros recursos de automação quando apropriado.
Determinar o tipo de aplicação
É importante determinar o tipo de aplicativo (multilocatário ou inquilino único) no início da fase de investigação para obter as informações corretas necessárias para entrar em contato com o proprietário do aplicativo. Para obter mais informações, consulte Locação no Microsoft Entra ID.
Aplicativos multilocatários
Para aplicativos multilocatário, o aplicativo é hospedado e gerenciado por terceiros. Identifique o processo necessário para entrar em contato e relatar problemas ao proprietário do aplicativo.
Aplicativos de locatário único
Encontre os detalhes de contato do proprietário do aplicativo em sua organização. Você pode encontrá-lo na guia Proprietários na seção Aplicativos Empresariais. Como alternativa, sua organização pode ter um banco de dados com essas informações.
Você também pode executar esta consulta do Microsoft Graph:
GET https://graph.microsoft.com/v1.0/applications/{id}/owners
Verificar Proteção de Identidade - identidades de carga de trabalho arriscadas
Este recurso está em visualização no momento da redação deste manual e os requisitos de licenciamento se aplicam ao seu uso. Identidades de carga de trabalho arriscadas podem ser o gatilho para investigar uma Entidade de Serviço, mas também podem ser usadas para investigar ainda mais outros gatilhos que você identificou. Você pode verificar o Estado de Risco de uma Entidade de Serviço usando a guia Proteção de Identidade - identidades de carga de trabalho arriscadas ou pode usar a API do Microsoft Graph.
Verificar se há um comportamento de entrada incomum
O primeiro passo da investigação é procurar evidências de padrões de autenticação incomuns no uso da entidade de serviço. No portal do Azure, no Azure Monitor, no Microsoft Sentinel ou no sistema de Gerenciamento de Informações de Segurança e Eventos (SIEM) de sua organização, procure o seguinte na seção Entradas da entidade de serviço:
- Localização - a entidade de serviço está a autenticar-se a partir de localizações\endereços IP que não seria de esperar?
- Falhas - há um grande número de falhas de autenticação para a entidade de serviço?
- Carimbos de data/hora - há autenticações bem-sucedidas que estão ocorrendo em momentos que você não esperaria?
- Frequência - existe um aumento da frequência de autenticações para a entidade de serviço?
- Credenciais de vazamento - as credenciais do aplicativo são codificadas e publicadas em uma fonte pública como o GitHub?
Se você implantou o Microsoft Entra ID Identity Protection - identidades de carga de trabalho arriscadas, verifique as deteções de Entradas suspeitas e Vazamento de credenciais. Para obter mais informações, consulte Detenções de risco de identidade de carga de trabalho.
Verificar o recurso de destino
Em Entradas da entidade de serviço, verifique também o recurso que a entidade de serviço estava acessando durante a autenticação. É importante obter informações do proprietário do aplicativo porque ele está familiarizado com quais recursos a Entidade de Serviço deve acessar.
Verificar se há alterações anormais nas credenciais
Use os logs de auditoria para obter informações sobre alterações de credenciais em aplicativos e entidades de serviço. Filtrar por categoria por gerenciamento de aplicativos e atividade por aplicativo de atualização – Gerenciamento de certificados e segredos.
- Verifique se há credenciais recém-criadas ou inesperadas atribuídas à entidade de serviço.
- Verifique se há credenciais na entidade de serviço usando a API do Microsoft Graph.
- Verifique o aplicativo e os objetos de entidade de serviço associados.
- Verifique qualquer função personalizada que você criou ou modificou. Observe as permissões marcadas abaixo:
Se você implantou a governança de aplicativos no Microsoft Defender for Cloud Apps, verifique o portal do Azure para alertas relacionados ao aplicativo. Para obter mais informações, consulte Introdução à deteção e correção de ameaças de aplicativos.
Se você implantou o Identity Protection, verifique o relatório "Deteções de risco" e o "histórico de riscos" da identidade do usuário ou da carga de trabalho.
Se você implantou o Microsoft Defender for Cloud Apps, verifique se a política "Adição incomum de credenciais a um aplicativo OAuth" está habilitada e verifique se há alertas abertos.
Para obter mais informações, consulte Adição incomum de credenciais a um aplicativo OAuth.
Além disso, você pode consultar as APIs servicePrincipalRiskDetections e user riskDetections para recuperar essas deteções de risco.
Pesquisar alterações anômalas na configuração do aplicativo
- Verifique as permissões de API atribuídas ao aplicativo para garantir que as permissões sejam consistentes com o que é esperado para o aplicativo.
- Verifique os logs de auditoria (filtre a atividade por aplicativo de atualização ou entidade de serviço de atualização).
- Confirme se as cadeias de conexão são consistentes e se a URL de saída foi modificada.
- Confirme se os domínios no URL estão alinhados com os registados.
- Determine se alguém adicionou um URL de redirecionamento não autorizado.
- Confirme a propriedade do URI de redirecionamento que você possui para garantir que ele não expirou e foi reivindicado por um adversário.
Além disso, se você implantou o Microsoft Defender for Cloud Apps, verifique o portal do Azure para alertas relacionados ao aplicativo que você está investigando no momento. Nem todas as políticas de alerta estão habilitadas por padrão para aplicativos OAuth, portanto, certifique-se de que todas essas políticas estejam habilitadas. Para obter mais informações, consulte as políticas do aplicativo OAuth. Você também pode exibir informações sobre a prevalência de aplicativos e a atividade recente na guia Aplicativos OAuth de investigação>.
Verificar se há funções suspeitas do aplicativo
- Você também pode usar os logs de auditoria. Filtre a atividade por Adicionar atribuição de função de aplicativo à entidade de serviço.
- Confirme se as funções atribuídas têm alto privilégio.
- Confirme se esses privilégios são necessários.
Verificar se há aplicativos comerciais não verificados
- Verifique se as aplicações da galeria comercial (versões publicadas e verificadas) estão a ser utilizadas.
Verifique se há indicações de divulgação de informações de propriedade keyCredential
Analise seu locatário para obter informações sobre possíveis informações de propriedade keyCredential, conforme descrito em CVE-2021-42306.
Para identificar e corrigir aplicativos Microsoft Entra afetados associados a contas Run-As de automação afetadas, navegue até a orientação de correção do GitHub Repo.
Importante
Se você descobrir evidências de comprometimento, é importante seguir as etapas destacadas nas seções de contenção e recuperação. Essas etapas ajudam a lidar com o risco, mas realizam uma investigação mais aprofundada para entender a origem do compromisso para evitar mais impacto e garantir que os agentes mal-intencionados sejam removidos.
Existem dois métodos principais de obter acesso aos sistemas através do uso de aplicativos. O primeiro envolve um aplicativo sendo consentido por um administrador ou usuário, geralmente por meio de um ataque de phishing. Este método faz parte do acesso inicial a um sistema e é frequentemente referido como "phishing de consentimento".
O segundo método envolve uma conta de administrador já comprometida criando um novo aplicativo para fins de persistência, coleta de dados e para ficar sob o radar. Por exemplo, um administrador comprometido pode criar um aplicativo OAuth com um nome aparentemente inócuo, evitando a deteção e permitindo o acesso de longo prazo aos dados sem a necessidade de uma conta. Este método é frequentemente visto em ataques de Estados-nação.
Aqui estão algumas das medidas que podem ser tomadas para investigar mais.
Verifique o Microsoft 365 Unified Audit Log (UAL) para obter indicações de phishing nos últimos sete dias
Às vezes, quando os atacantes usam aplicativos maliciosos ou comprometidos como meio de persistência ou para exfiltrar dados, uma campanha de phishing está envolvida. Com base nas descobertas das etapas anteriores, você deve revisar as identidades de:
- Proprietários de Aplicações
- Administradores de consentimento
Analise as identidades em busca de indícios de ataques de phishing nas últimas 24 horas. Aumente esse período de tempo, se necessário, para 7, 14 e 30 dias se não houver indicações imediatas. Para obter um manual detalhado de investigação de phishing, consulte o Manual de investigação de phishing.
Pesquisar consentimentos de aplicativos maliciosos nos últimos sete dias
Para adicionar um aplicativo a um locatário, os invasores falsificam usuários ou administradores para consentir com aplicativos. Para saber mais sobre os sinais de um ataque, consulte o Application Consent Grant Investigation Playbook.
Verificar o consentimento do aplicativo sinalizado
Verificar logs de auditoria
Para ver todas as concessões de consentimento para esse aplicativo, filtre Atividade por Consentimento para o aplicativo.
Usar os logs de auditoria do centro de administração do Microsoft Entra
Usar o Microsoft Graph para consultar os logs de auditoria
a) Filtrar para um período de tempo específico:
GET https://graph.microsoft.com/v1.0/auditLogs/auditLogs/directoryAudits?&$filter=activityDateTime le 2022-01-24
b) Filtre os logs de auditoria para entradas de log de auditoria de 'Consentimento para Aplicativos':
https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?directoryAudits?$filter=ActivityType eq 'Consent to application'
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#auditLogs/directoryAudits",
"value": [
{
"id": "Directory_0da73d01-0b6d-4c6c-a083-afc8c968e655_78XJB_266233526",
"category": "ApplicationManagement",
"correlationId": "aaaa0000-bb11-2222-33cc-444444dddddd",
"result": "success",
"resultReason": "",
"activityDisplayName": "Consent to application",
"activityDateTime": "2022-03-25T21:21:37.9452149Z",
"loggedByService": "Core Directory",
"operationType": "Assign",
"initiatedBy": {
"app": null,
"user": {
"id": "8b3f927e-4d89-490b-aaa3-e5d4577f1234",
"displayName": null,
"userPrincipalName": "admin@contoso.com",
"ipAddress": "55.154.250.91",
"userType": null,
"homeTenantId": null,
"homeTenantName": null
}
},
"targetResources": [
{
"id": "d23d38a1-02ae-409d-884c-60b03cadc989",
"displayName": "Graph explorer (official site)",
"type": "ServicePrincipal",
"userPrincipalName": null,
"groupType": null,
"modifiedProperties": [
{
"displayName": "ConsentContext.IsAdminConsent",
"oldValue": null,
"newValue": "\"True\""
},
c) Usar o Log Analytics
AuditLogs
| where ActivityDisplayName == "Consent to application"
Para obter mais informações, consulte o Application Consent Grant Investigation Playbook.
Determinar se houve consentimento suspeito do usuário final para o aplicativo
Um usuário pode autorizar um aplicativo a acessar alguns dados no recurso protegido, enquanto age como esse usuário. As permissões que permitem esse tipo de acesso são chamadas de "permissões delegadas" ou consentimento do usuário.
Para encontrar aplicativos que são consentidos pelos usuários, use o LogAnalytics para pesquisar os logs de auditoria:
AuditLogs
| where ActivityDisplayName == "Consent to application" and (parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)) <> "True")
Verifique os logs de auditoria para descobrir se as permissões concedidas são muito amplas (em todo o locatário ou consentidas pelo administrador)
Revisar as permissões concedidas a um aplicativo ou entidade de serviço pode ser uma tarefa demorada. Comece por compreender as permissões potencialmente arriscadas no Microsoft Entra ID.
Agora, siga as orientações sobre como enumerar e revisar permissões na investigação de concessão de consentimento do aplicativo.
Verifique se as permissões foram concedidas por identidades de usuário que não deveriam ter a capacidade de fazer isso ou se as ações foram executadas em datas e horários estranhos
Revise usando logs de auditoria:
AuditLogs
| where OperationName == "Consent to application"
//| where parse_json(tostring(TargetResources[0].modifiedProperties))[4].displayName == "ConsentAction.Permissions"
Você também pode usar os logs de auditoria do Microsoft Entra, filtrados por Consentimento ao aplicativo. Na seção Detalhes do Log de Auditoria, clique em Propriedades Modificadas e examine ConsentAction.Permissions:
Etapas de contenção
Depois de identificar um ou mais aplicativos ou identidades de carga de trabalho como mal-intencionados ou comprometidos, talvez você não queira rolar imediatamente as credenciais desse aplicativo, nem excluir imediatamente o aplicativo.
Importante
Antes de executar a etapa a seguir, sua organização deve avaliar o impacto na segurança e o impacto nos negócios da desativação de um aplicativo. Se o impacto comercial da desativação de um aplicativo for muito grande, considere preparar e passar para o estágio de recuperação desse processo.
Desativar aplicativo comprometido
Uma estratégia de contenção típica envolve a desativação de entradas no aplicativo identificado, para dar à sua equipe de resposta a incidentes ou à unidade de negócios afetada tempo para avaliar o impacto da exclusão ou da rolagem de chaves. Se sua investigação levar você a acreditar que as credenciais da conta de administrador também estão comprometidas, esse tipo de atividade deve ser coordenado com um evento de despejo para garantir que todas as rotas para acessar o locatário sejam cortadas simultaneamente.
Você também pode usar o seguinte código do Microsoft Graph PowerShell para desabilitar a entrada no aplicativo:
# The AppId of the app to be disabled
$appId = "{AppId}"
# Check if a service principal already exists for the app
$servicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$appId'"
if ($servicePrincipal) {
# Service principal exists already, disable it
$ServicePrincipalUpdate =@{
"accountEnabled" = "false"
}
Update-MgServicePrincipal -ServicePrincipalId $servicePrincipal.Id -BodyParameter $ServicePrincipalUpdate
} else {
# Service principal does not yet exist, create it and disable it at the same time
$ServicePrincipalID=@{
"AppId" = $appId
"accountEnabled" = "false"
}
$servicePrincipal = New-MgServicePrincipal -BodyParameter $ServicePrincipalId
}
Etapas de recuperação
Remediar entidades de serviço
Liste todas as credenciais atribuídas à entidade de serviço de risco. A melhor maneira de fazer isso é executar uma chamada do Microsoft Graph usando GET ~/application/{id} onde o ID passado é o ID do objeto do aplicativo.
Analise a saída em busca de credenciais. A saída pode conter passwordCredentials ou keyCredentials. Grave os keyIds para todos.
"keyCredentials": [], "parentalControlSettings": { "countriesBlockedForMinors": [], "legalAgeGroupRule": "Allow" }, "passwordCredentials": [ { "customKeyIdentifier": null, "displayName": "Test", "endDateTime": "2021-12-16T19:19:36.997Z", "hint": "7~-", "keyId": "aaaaaaaa-0b0b-1c1c-2d2d-333333333333", "secretText": null, "startDateTime": "2021-06-16T18:19:36.997Z" } ],
Adicione uma nova credencial de certificado (x509) ao objeto do aplicativo usando a API addKey do aplicativo.
POST ~/applications/{id}/addKeyRemova imediatamente todas as credenciais antigas. Para cada credencial de senha antiga, remova-a usando:
POST ~/applications/{id}/removePasswordPara cada credencial de chave antiga, remova-a usando:
POST ~/applications/{id}/removeKeyCorrija todas as Entidades de Serviço associadas ao aplicativo. Siga esta etapa se o locatário hospedar/registrar um aplicativo multilocatário e/ou registrar várias entidades de serviço associadas ao aplicativo. Execute etapas semelhantes às listadas anteriormente:
GET ~/servicePrincipals/{id}
Encontre passwordCredentials e keyCredentials na resposta, registre todos os keyIds antigos
Remova todas as credenciais de chave e senha antigas. Utilizar:
POST ~/servicePrincipals/{id}/removePassword and POST ~/servicePrincipals/{id}/removeKey for this, respectively.
Remediar os recursos afetados da Entidade de Serviço
Corrija os segredos do KeyVault aos quais a Entidade de Serviço tem acesso girando-os, na seguinte prioridade:
- Segredos diretamente expostos com chamadas GetSecret .
- O resto dos segredos em KeyVaults expostos.
- O resto dos segredos nas subscrições expostas.
Para obter mais informações, consulte Removendo e rolando interativamente os certificados e segredos de uma entidade de serviço ou aplicativo.
Para obter orientações do Microsoft Entra SecOps sobre aplicativos, consulte Guia de operações de segurança do Microsoft Entra para aplicativos.
Por ordem de prioridade, este cenário seria:
- Atualize os cmdlets do Graph PowerShell (Add/Remove ApplicationKey + ApplicationPassword) para incluir exemplos de substituição de credenciais.
- Adicione cmdlets personalizados ao Microsoft Graph PowerShell que simplificam esse cenário.
Desativar ou excluir aplicativos mal-intencionados
Um aplicativo pode ser desativado ou excluído. Para desativar o aplicativo, em Habilitado para que os usuários entrem, mova a alternância para Não.
Você pode excluir o aplicativo, temporária ou permanentemente, no portal do Azure ou por meio da API do Microsoft Graph. Quando você exclui suavemente, o aplicativo pode ser recuperado até 30 dias após a exclusão.
DELETE /applications/{id}
Para excluir permanentemente o aplicativo, use esta chamada da API do Microsoft Graph:
DELETE /directory/deletedItems/{id}
Se você desabilitar ou excluir suavemente o aplicativo, configure o monitoramento nos logs de auditoria do Microsoft Entra para saber se o estado muda novamente para habilitado ou recuperado.
Registro em log para habilitado:
- Serviço - Diretório Principal
- Tipo de atividade - Atualizar entidade de serviço
- Categoria - Gestão de Aplicações
- Iniciado por (ator) - UPN de ator
- Alvos - ID do aplicativo e nome de exibição
- Propriedades modificadas - Nome da propriedade = conta habilitada, novo valor = true
Registo para recuperados:
- Serviço - Diretório Principal
- Tipo de atividade - Adicionar entidade de serviço
- Categoria - Gestão de Aplicações
- Iniciado por (ator) - UPN de ator
- Alvos - ID do aplicativo e nome de exibição
- Propriedades modificadas - Nome da propriedade = conta habilitada, novo valor = true
Nota
A Microsoft desativa globalmente as aplicações que violam os seus Termos de Serviço. Nesses casos, esses aplicativos são exibidos DisabledDueToViolationOfServicesAgreement na disabledByMicrosoftStatus propriedade nos tipos de recursos de entidade de serviço e aplicativo relacionados no Microsoft Graph. Para evitar que eles sejam instanciados em sua organização novamente no futuro, não é possível excluir esses objetos.
Implementar o Identity Protection para identidades de carga de trabalho
A Microsoft deteta o risco em identidades de carga de trabalho no comportamento de entrada e indicadores offline de comprometimento.
Para obter mais informações, consulte Protegendo identidades de carga de trabalho com a Proteção de identidade.
Esses alertas aparecem no portal da Proteção de Identidade e podem ser exportados para as ferramentas SIEM por meio das Configurações de Diagnóstico ou das APIs de Proteção de Identidade.
Acesso condicional para identidades de carga de trabalho arriscadas
O Acesso Condicional permite bloquear o acesso a contas específicas que designa quando a Proteção de Identidade as marca como "em risco". Atualmente, a imposição por meio do Acesso Condicional está limitada apenas a aplicativos de locatário único.
Para obter mais informações, consulte Acesso condicional para identidades de carga de trabalho.
Implementar políticas de risco de aplicativos
Rever as definições de consentimento do utilizador
Revise as configurações de consentimento do usuário em Aplicativos>corporativos do Microsoft Entra ID>Configurações de consentimento e permissões>do usuário.
Para rever as opções de configuração, consulte Configurar a forma como os utilizadores consentem com as aplicações.
Implementar fluxo de consentimento de administrador
Quando um desenvolvedor de aplicativos direciona os usuários para o ponto de extremidade de consentimento de administrador com a intenção de dar consentimento para todo o locatário, isso é conhecido como fluxo de consentimento de administrador. Para garantir que o fluxo de consentimento de administrador funcione corretamente, os desenvolvedores de aplicativos devem listar todas as permissões na propriedade RequiredResourceAccess no manifesto do aplicativo.
A maioria das organizações desativa a capacidade de seus usuários consentirem com aplicativos. Para dar aos usuários a capacidade de ainda solicitar consentimento para aplicativos e ter capacidade de revisão administrativa, é recomendável implementar o fluxo de trabalho de consentimento de administrador. Siga as etapas do fluxo de trabalho de consentimento de administrador para configurá-lo em seu locatário.
Para operações com privilégios elevados, como o consentimento do administrador, tenha uma estratégia de acesso privilegiado definida nas nossas orientações.
Rever as definições de consentimento de intensificação com base no risco
O consentimento intensificado baseado no risco ajuda a reduzir a exposição do utilizador a aplicações maliciosas. Por exemplo, solicitações de consentimento para aplicativos multilocatários recém-registrados que não são verificados pelo editor e exigem permissões não básicas são consideradas arriscadas. Se uma solicitação de consentimento de usuário arriscada for detetada, a solicitação exigirá um "passo" para o consentimento do administrador. Esse recurso de step-up é habilitado por padrão, mas resulta em uma alteração de comportamento somente quando o consentimento do usuário está habilitado.
Certifique-se de que está ativado no seu inquilino e reveja as definições de configuração descritas aqui.
Referências
- Manuais de resposta a incidentes
- Concessão de consentimento do aplicativo
- Riscos da Proteção de ID do Microsoft Entra
- Guia de monitoramento de segurança do Microsoft Entra
- Conceitos de auditoria de aplicativos
- Configurar a forma como os utilizadores concedem consentimento às aplicações
- Configurar o fluxo de trabalho de consentimento de administrador
- Adição incomum de credenciais a um aplicativo OAuth
- Protegendo identidades de carga de trabalho com a Proteção de Identidade
- Sinais holísticos de identidade comprometida da Microsoft
Manuais adicionais de resposta a incidentes
Examine as orientações para identificar e investigar esses tipos adicionais de ataques:
Recursos de resposta a incidentes
- Visão geral dos produtos e recursos de segurança da Microsoft para analistas recém-chegados às funções e experientes
- Planejando seu Centro de Operações de Segurança (SOC)
- Resposta a incidentes do Microsoft Defender XDR
- Microsoft Defender para Cloud (Azure)
- Resposta a incidentes do Microsoft Sentinel
- O guia da equipe de Resposta a Incidentes da Microsoft compartilha práticas recomendadas para equipes e líderes de segurança
- Os guias de Resposta a Incidentes da Microsoft ajudam as equipas de segurança a analisar atividades suspeitas