Investigação de aplicativos comprometidos e mal-intencionados

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: Aborda os requisitos específicos que você precisa concluir antes de 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.
  • Workflow: Mostra o fluxo lógico que você deve seguir para executar essa investigação.
  • Etapas de investigação: Inclui uma orientação passo a passo detalhada para essa 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 como recuperar/atenuar 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

Fluxograma detalhado das etapas de investigação.

Etapas de investigação

Para esta investigação, suponha que você tenha uma indicação de um possível comprometimento do aplicativo na forma de um relatório de um usuário, exemplo de logs de entrada do Microsoft Entra, ou uma detecção de proteção de identidade. Certifique-se de concluir e habilitar todas as etapas pré-requisitas.

Este guia estratégico é criado com a intenção de que nem todos os clientes Microsoft e suas equipes de investigação tenham a Microsoft 365 E5 completa ou Microsoft Entra ID pacote de licenças 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, consulte Tenancy no Microsoft Entra ID.

Aplicativos multilocatário

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 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 fase de testes no momento da elaboração deste guia 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 um Principal de Serviço usando a guia Identity Protection – identidades de carga de trabalho arriscadas ou pode usar o Microsoft API do Graph. Você também pode usar comandos de linguagem natural para obter insights sobre identidades de trabalho arriscadas com Microsoft Security Copilot em Microsoft Entra.

Captura de tela da página do portal Detalhes da Detecção de Riscos.

Captura de tela da interface do usuário da página de detalhes da Detecção de Riscos.

Uma amostra da detecção de risco do Principal de Serviço API do Graph.

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 do Principal de Serviço. No portal Azure, Azure Monitor, 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 Consendos principais de serviço seção:

  • Localização - a Entidade de serviço está autenticando a partir de localizações\endereços IP que você não esperaria?
  • Falhas - há um grande número de falhas de autenticação para o Principal do 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 o Principal do serviço?
  • Credenciais de Vazamento – alguma credencial de aplicativo é codificada e publicada em uma fonte pública como GitHub?

Se você implantou o Microsoft Entra ID Identity Protection – identidades de trabalho em risco, verifique as detecções de Entradas Suspeitas e Credenciais Vazadas. Para obter mais informações, consulte detenções de risco de identidade de carga de trabalho.

Verifique o recurso de destino

Nas entradas de logon do Principal do Serviço, verifique também o recurso que estava sendo acessado pela Entidade de Serviço durante a autenticação. É importante receber informações do proprietário do aplicativo porque ele está familiarizado com quais recursos o Principal de Serviço deve acessar.

Captura de tela de como verificar o recurso para o Principal do 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 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 ao principal de serviço.
  • Verifique se há credenciais no Principal de Serviço usando Microsoft API do 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:

Captura de tela de como verificar as funções personalizadas que foram criadas ou modificadas.

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

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

Captura de tela da interface do usuário do portal de Detecção de Riscos.

Se você implantou Microsoft Defender para Aplicativos de 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, veja Adição invulgar de credenciais a uma aplicação 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.
  • Verificar logs de auditoria (filtrar Atividade por Atualizar Aplicativo ou Atualizar Principal do 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 ela não expirou e não foi reivindicada por um adversário.

Além disso, se você implantou Microsoft Defender para Aplicativos de Nuvem, verifique o portal de 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 as políticas de aplicativo OAuth. Você também pode exibir informações sobre a prevalência dos apps e a atividade recente na guiade Investigação>Aplicativos OAuth.

Verifique se há funções de aplicativo suspeitas

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

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

Para identificar e corrigir aplicativos Microsoft Entra afetados associados a contas de Automação Run-As, navegue até o repositório GitHub de orientação para remediação.

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 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 Microsoft 365 UAL (Unified Audit Log) 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 detalhado, 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 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 a Atividade por Consentimento para o aplicativo.

  • Usar os Logs de Auditoria do Microsoft Entra Admin Center

  • Usar 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": "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 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 do 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 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 de risco no Microsoft Entra ID.

Agora, siga as diretrizes sobre como enumerar e examinar 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

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 Microsoft Entra e filtrar por Consentimento para o aplicativo. Na seção detalhes do Log de Auditoria, clique em Propriedades Modificadas e, em seguida, examine ConsentAction.Permissions:

Captura de tela de como usar os logs de auditoria do Microsoft Entra.

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 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 contenção envolve a desativação de logins 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.

Captura de tela de como desabilitar a entrada do usuário.

Você também pode usar o seguinte código 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 de Risco . A melhor maneira de fazer isso é executar uma chamada Microsoft Graph usando GET ~/application/{id} em que a ID passou é a 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": "aaaaaaaa-0b0b-1c1c-2d2d-333333333333",
             "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 hospeda/registra um aplicativo multilocatário e/ou registra várias entidades de serviço associadas ao aplicativo. Execute etapas semelhantes às listadas anteriormente:

  • GET ~/servicePrincipals/{id}

  • Encontre passwordCredentials e keyCredentials na resposta e 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 através de chamadas GetSecret.
  • O restante dos segredos em KeyVaults expostos.
  • O restante dos segredos nas assinaturas expostas.

Para obter mais informações, consulte Removendo e renovando interativamente os certificados e segredos de um Principal do Serviço ou Aplicativo.

Para obter orientação do Microsoft Entra SecOps sobre aplicativos, consulte o 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 para o Microsoft Graph PowerShell que simplifiquem esse cenário.

Desabilitar ou excluir aplicativos mal-intencionados

Um aplicativo pode ser desabilitado ou excluído. Para desabilitar o aplicativo, em Habilitado para que os usuários entrem, mova a alternância para Não.

Você pode excluir o aplicativo, temporariamente ou permanentemente, no portal do Azure ou por meio do microsoft API do 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 do Microsoft API do Graph:

DELETE /directory/deletedItems/{id}

Se você desabilitar ou excluir temporariamente o aplicativo, configure o monitoramento nos logs de auditoria do Microsoft Entra para saber se o estado muda de volta para habilitado ou recuperado.

Registro ativado para:

  • Serviço – Diretório Principal
  • Tipo de atividade – Atualizar Entidade de Serviço
  • Categoria – Gerenciamento de Aplicativos
  • Iniciado por (ator) – UPN do ator
  • Destinos – ID do aplicativo e nome de exibição
  • Propriedades modificadas – Nome da propriedade = conta habilitada, novo valor = true

Registro em log para recuperação:

  • Serviço – Diretório Principal
  • Tipo de atividade – Adicionar Principal de Serviço
  • Categoria – Gerenciamento de Aplicativos
  • Iniciado por (ator) – UPN do ator
  • Destinos – ID do aplicativo e nome de exibição
  • Propriedades Modificadas – Nome da propriedade = conta habilitada, novo valor = true

Observação

Microsoft desabilita globalmente os aplicativos que estão violando seus Termos de Serviço. Nesses casos, esses aplicativos mostram DisabledDueToViolationOfServicesAgreement na propriedade disabledByMicrosoftStatus nos tipos de recursos aplicativo e principal do serviço no Microsoft Graph. Para impedir que eles sejam instanciados em sua organização novamente no futuro, não exclua esses objetos.

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

Microsoft detecta riscos em identidades em cargas de trabalho com base no comportamento de autenticação e indicadores offline de comprometimento.

Para obter mais informações, consulte Protegendo identidades de cargas de trabalho com a Proteção de Identidade.

Esses alertas aparecem no portal do Identity Protection e podem ser exportados para ferramentas SIEM por meio das Configurações de Diagnóstico ou das APIs de Proteção de Identidade.

Captura de tela de como examinar 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". Atualmente, a imposição por meio do Acesso Condicional está limitada apenas a aplicativos de locatário único.

Captura de tela de como 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

Examine as configurações de consentimento do usuário em Microsoft Entra ID>Enterprise applications>Consent and permissions>User consent settings.

Captura de tela de como permitir o consentimento do usuário para aplicativos.

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

Quando um desenvolvedor de aplicativos direciona os usuários para o endpoint de consentimento administrativo com a intenção de dar o consentimento para o tenant completo, 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 aplicativos e ter capacidade de revisão administrativa, é recomendável implementar o fluxo de trabalho de consentimento do administrador. Siga as etapas de fluxo de trabalho de consentimento do administrador para configurá-lo em seu locatário.

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

O consentimento incremental baseado em risco ajuda a reduzir a exposição do usuário a aplicativos maliciosos. 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 ele 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

  • Last updated on