Compartilhar via

Investigação de aplicativos comprometidos e mal-intencionados

  • Artigo

Este artigo fornece diretrizes 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 realizar a ação corretiva necessária para proteger informações e minimizar outros riscos.

  • Pré-requisitos: esta seção cobre os requisitos específicos que você precisa concluir para iniciar a investigação. Por exemplo, os registros em log que devem ser ativados, as funções e as permissões necessárias, entre outros.
  • Fluxo de trabalho: mostra o fluxo lógico que você deve seguir para executar esta investigação.
  • Etapas de investigação: esta seção inclui diretrizes passo a passo detalhadas desta investigação específica.
  • Etapas de contenção: contém etapas sobre como desabilitar os aplicativos comprometidos.
  • Etapas de recuperação: contém etapas de alto nível sobre a recuperação e a mitigação de um ataque mal-intencionado em aplicativos comprometidos.
  • Referências: contém outros materiais de leitura e referência.

Pré-requisitos

Antes de iniciar a investigação, verifique se você tem as ferramentas e permissões corretas para coletar informações detalhadas.

Ferramentas necessárias

Para obter uma investigação eficaz, instale o seguinte módulo do PowerShell e o kit de ferramentas em sua máquina de investigação:

Workflow

Fluxo detalhado das etapas de investigação

Etapas de investigação

Para esta investigação, suponha que você tenha uma indicação para 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 detecção de proteção de identidade. Certificar-se de concluir e habilitar todas as etapas de pré-requisito necessárias.

Este guia estratégico foi criado considerando que nem todos os clientes da Microsoft e suas equipes de investigação tem o pacote de licenças completo do Microsoft 365 E5 ou do Microsoft Entra ID P2 disponível ou configurado. Este guia estratégico destaca outros recursos de automação quando apropriado.

Determinar o tipo de aplicativo

É importante determinar o tipo de aplicativo (multi ou único locatário) 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, confira Locação no Microsoft Entra ID.

Aplicativos multilocatários

Para aplicativos multilocatário, o aplicativo é hospedado e gerenciado por terceiros. Identificar o processo necessário para entrar em contato e relatar problemas ao proprietário do aplicativo.

Aplicativos de locatário único

Encontrar 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 a Proteção de Identidade - identidades de carga de trabalho arriscadas

Esse recurso está em visualização no momento de preparação deste guia estratégico 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 mais a fundo 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 também a API do Microsoft Graph.

Portal de detecção de risco

Detalhes de detecção de risco

Um exemplo da API do Graph de Detecção de Riscos da Entidade de Serviço

Verificar se há comportamento de entrada incomum

A primeira etapa 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 SIEM (Gerenciamento de Eventos e Informações de Segurança) de sua organização, procure o seguinte na seção Entradas de entidades de serviço:

  • Localização - a Entidade de serviço está autenticando a partir de localizações\endereços IP que você não esperaria?
  • Falhas - existe um grande número de falhas de autenticação para 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 - há um aumento da frequência de autenticações para a Entidade de serviço?
  • Credenciais vazadas - quaisquer credenciais de aplicativo são codificadas e publicadas em uma fonte pública como o GitHub?

Se você implantou a Proteção de identidade Entra ID - identidades de carga de trabalho arriscadas, verifique as detecções de Entradas Suspeitas e Credenciais Vazadas. Para obter mais informações, consulte detecções de risco da identidade de carga de trabalho.

Verifique o recurso de destino

Nas 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 o recurso de entidade de serviço

Verificar se há alterações anormais nas credenciais

Use Logs de auditoria para obter informações sobre alterações de credenciais em aplicativos e entidades de serviço. Filtrar por Categoria por Gerenciamento do aplicativo, e Atividade por Atualizar aplicativo: 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:

Verificar as funções personalizadas que foram criadas ou modificadas

Se você implantou a governança do aplicativo no Microsoft Defender para Aplicativos de Nuvem, verifique o portal do Azure para obter alertas relacionados ao aplicativo. Para obter mais informações, consulte Introdução à detecção de ameaças e correção.

Se você implantou a Proteção de Identidade, verifique o relatório "Detecções de risco" e no "histórico de risco" da identidade do usuário ou da carga de trabalho.

Portal de detecção de risco

Se você implantou o Microsoft Defender para aplicativos na nuvem, 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 riskDetections do usuário para recuperar essas detecções de risco.

Procurar 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 (filtrar Atividade por Atualizar aplicativo ou Atualizar Entidade de Serviç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 na URL estão alinhados com os registrados.
  • Determine se alguém adicionou uma URL de redirecionamento não autorizada.
  • Confirme a propriedade do URI de redirecionamento que você possui para garantir que ele não expirou e foi reivindicada por um adversário.

Além disso, se você implantou o Microsoft Defender para Aplicativos de Nuvem, verifique o portal do Azure para obter alertas relacionados ao aplicativo que você está investigando no momento. Nem todas as políticas de alerta sã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 Políticas de aplicativo OAuth. Você também pode exibir informações sobre a prevalência de aplicativos e a atividade recente na guia Investigação>Aplicativos OAuth.

Verifique se há funções de aplicativo suspeitas

  • Você também pode usar os logs de auditoria. Filtrar Atividade por Adicionar atribuição de função do 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.

Verifique se há aplicativos comerciais não verificados

  • Verifique se os aplicativos de galeria comercial (versões publicadas e verificadas) estão sendo usados.

Verifique se há indicações de divulgação de informações de propriedade keyCredential

Revise seu locatário para obter a possível divulgação de informações de propriedade keyCredential, conforme descrito em CVE-2021-42306.

Para identificar e corrigir aplicativos Microsoft Entra afetados associados a contas Executórias de Automação afetadas, navegue até as diretrizes de correção GitHub Repo.

Importante

Evidência de comprometimento: se você descobrir evidências de comprometimento, é importante tomar as medidas 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 comprometimento para evitar mais impacto e garantir que os atores 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 fora do radar. Por exemplo, um administrador comprometido poderia criar um aplicativo OAuth com um nome aparentemente inócuo, evitando a detecção e permitindo acesso de longo prazo aos dados sem a necessidade de uma conta. Este método é frequentemente visto em ataques de estado-nação.

Aqui estão algumas das etapas que podem ser tomadas para investigar mais.

Verifique o UAL (Log de Auditoria Unificado) do Microsoft 365 para obter indicações de phishing nos últimos sete dias

Às vezes, quando os invasores usam aplicativos mal-intencionados 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 aplicativo
  • Administradores de consentimento

Revise 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 guia estratégico de investigação de phishing detalhada, consulte o Guia estratégico de investigação de Phishing.

Procure consentimentos de aplicativos mal-intencionados nos últimos sete dias

Para obter um aplicativo adicionado a um locatário, os invasores falsificam usuários ou administradores para consentir com o uso de aplicativos. Para saber mais sobre os sinais de um ataque, consulte o Guia estratégico de Investigação de Concessão de Consentimento de Aplicativos.

Verifique os logs de auditoria

Para ver todas as concessões de consentimento para esse aplicativo, filtre Atividade por Consentimento para aplicativos.

  • Use 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) Filtrar os Logs de Auditoria para as 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": "0da73d01-0b6d-4c6c-a083-afc8c968e655",
        "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 Guia estratégico de Investigação de Concessão de Consentimento de Aplicativos.

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 localizar 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 Logs de auditoria para descobrir se as permissões concedidas são muito amplas (em todo o locatário ou com consentimento do administrador)

Revisar as permissões concedidas a um aplicativo ou entidade de serviço pode ser uma tarefa demorada. Comece entendendo as permissões potencialmente arriscadas no Microsoft Entra ID.

Agora, siga as diretrizes sobre como enumerar e revisar permissões na investigação de concessão de consentimento de aplicativos.

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

Revisão com o uso de 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 para aplicativos. Na seção Detalhes do Log de Auditoria, clique em Propriedades Modificadas e revise o ConsentAction.Permissions:

Usar logs de auditoria do Microsoft Entra

Etapas de independência

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 para esse 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 desabilitação de um aplicativo. Se o impacto nos negócios da desativação de um aplicativo for muito grande, considere preparar e passar para o estágio de recuperação desse processo.

Desabilitar o aplicativo comprometido

Uma estratégia típica de independência 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 troca 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 remoção para garantir que todas as rotas para acessar o locatário sejam cortadas simultaneamente.

Alternar para desabilitar os usuários para entrar

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 da recuperação

Corrigir entidades de serviço

  1. Liste todas as credenciais atribuídas à Entidade de serviço arriscada. 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 para credenciais. A saída pode conter passwordCredentials ou keyCredentials. Registre os keyIds para todos.

      "keyCredentials": [],
     "parentalControlSettings": {
         "countriesBlockedForMinors": [],
         "legalAgeGroupRule": "Allow"
     },
     "passwordCredentials": [
         {
             "customKeyIdentifier": null,
             "displayName": "Test",
             "endDateTime": "2021-12-16T19:19:36.997Z",
             "hint": "7~-",
             "keyId": "9f92041c-46b9-4ebc-95fd-e45745734bef",
             "secretText": null,
             "startDateTime": "2021-06-16T18:19:36.997Z"
         }
     ],

  2. Adicione uma nova credencial de certificado (x509) ao objeto de aplicativo usando a API addKey do aplicativo.

    POST ~/applications/{id}/addKey

  3. Remova imediatamente todas as credenciais antigas. Para cada credencial de senha antiga, remova-a usando:

    POST ~/applications/{id}/removePassword

    Para cada credencial de chave antiga, remova-a usando:

    POST ~/applications/{id}/removeKey

  4. Corrija 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 antigas de senha e de chave. Use:

    POST ~/servicePrincipals/{id}/removePassword and POST ~/servicePrincipals/{id}/removeKey for this, respectively.

Corrigir os recursos afetados da entidade de serviço

Corrigir quaisquer segredos do KeyVault aos quais a Entidade de Serviço tem acesso, de acordo com a seguinte prioridade:

  • Segredos expostos diretamente com chamadas GetSecret.
  • O restante dos segredos em KeyVaults expostos.
  • O restante dos segredos nas assinaturas expostas.

Para obter mais informações, consulte Como remover e sobrepor interativamente os certificados e segredos de uma entidade de serviço ou aplicativo.

Para obter diretrizes do Microsoft Entra SecOps sobre aplicativos, consulte Guia de operações de segurança do Microsoft Entra para aplicativos.

Em ordem de prioridade, esse cenário seria:

  • Atualize o documento cmdlets do Graph PowerShell (Adicionar/Remover ApplicationKey + ApplicationPassword) para incluir exemplos de substituição de credenciais.
  • Adicione cmdlets personalizados ao Microsoft Graph PowerShell que simplificam esse cenário.

Desabilitar ou excluir aplicativos mal-intencionados

Um aplicativo pode ser desabilitado ou excluído. Para desabilitar o aplicativo, em Habilitado para os usuários entrarem, 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 temporariamente, 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 o aplicativo de forma flexível, configure o monitoramento nos logs de auditoria do Microsoft Entra para saber se o estado volta a ser habilitado ou recuperado.

Registro em log para habilitado:

  • Serviço - Diretório de Núcleo
  • Tipo de Atividade: atualizar entidade de serviço
  • Categoria: gerenciamento de aplicativos
  • Iniciado por (ator) - UPN do ator
  • Metas: ID do aplicativo e nome de exibição
  • Propriedades modificadas - Nome da propriedade = conta habilitada, novo valor = true

Registro em log para recuperados:

  • Serviço - Diretório de Núcleo
  • Tipo de Atividade - Adicionar entidade de serviço
  • Categoria: gerenciamento de aplicativos
  • Iniciado por (ator) - UPN do ator
  • Metas: ID do aplicativo e nome de exibição
  • Propriedades modificadas - Nome da propriedade = conta habilitada, novo valor = true

Nota: a Microsoft desabilita globalmente os aplicativos que violam seus Termos de Serviço. Nesses casos, esses aplicativos exibirão DisabledDueToViolationOfServicesAgreement na propriedade disabledByMicrosoftStatus nos tipos de recurso de aplicativo e entidade de serviço relacionados no Microsoft Graph. Para impedir que eles sejam instanciados em sua organização novamente no futuro, você não pode excluir esses objetos.

Implementar a Proteção de Identidade para identidades de carga de trabalho

A Microsoft detecta o risco em identidades de carga de trabalho em comportamento de entrada e indicadores offline de comprometimento.

Para 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 do SIEM por meio das Configurações de Diagnóstico ou das APIs de Proteção de Identidade.

Examinar os riscos e alertas no portal do Identity Protection

Acesso condicional para identidades de carga de trabalho arriscadas

O Acesso Condicional permite bloquear o acesso de contas específicas designadas quando a Proteção de Identidade as marca como "em risco". Observe que a imposição por meio do Acesso Condicional está atualmente limitada apenas a aplicativos de locatário único.

Controlar o acesso do usuário com base na política de acesso condicional

Para obter mais informações, consulte Acesso Condicional para identidades de carga de trabalho.

Implementar políticas de risco de aplicativos

Revisar as configurações de consentimento do usuário em Microsoft Entra ID>Aplicativos Empresariais>Consentimento e permissão>Configurações de consentimento do usuário.

Selecionar Permitir consentimento do usuário para aplicativos nas opções

Para revisar as opções de configuração, consulte Configurar como os usuários consentem com o uso dos aplicativos.

Quando um desenvolvedor de aplicativos direciona os usuários para o ponto de extremidade de consentimento do administrador com a intenção dar o consentimento para o locatário inteiro, isso é conhecido como fluxo de consentimento do administrador. Para garantir que o fluxo de consentimento do administrador funcione corretamente, os desenvolvedores de aplicativos precisam listar todas as permissões na propriedade RequiredResourceAccess no manifesto do aplicativo.

A maioria das organizações desabilita a capacidade de seus usuários consentirem com o uso de aplicativos. Para dar aos usuários a capacidade de ainda solicitar consentimento para usar aplicativos e ter capacidade de revisão administrativa, é recomendável implementar o fluxo de trabalho de consentimento do administrador. Siga as etapas do fluxo de trabalho de consentimento do administrador para configurá-lo em seu locatário.

Para operações com alto privilégio, como consentimento do administrador, tenha uma estratégia de acesso privilegiado definida em nossas diretrizes.

O consentimento de step-up baseado em risco ajuda a reduzir a exposição do usuário a aplicativos mal-intencionados. Por exemplo, as solicitações de consentimento para aplicativos multilocatários registrados recentemente, que não foram verificados pelo editor e exigem permissões não básicas, são consideradas arriscadas. Se uma solicitação de consentimento de usuário suspeito for detectada, a solicitação exigirá um "step-up" para consentimento do administrador. Essa capacidade de step-up é habilitada por padrão, mas só resulta em uma alteração de comportamento quando o consentimento do usuário está habilitado.

Verifique se está habilitado em seu locatário e examine as configurações descritas aqui.

Referências

Mais guias estratégicos de resposta a incidente

Examine as diretrizes para identificar e investigar esses tipos adicionais de ataques:

Recursos de resposta a incidentes