Investigação de fornecimento de consentimento do aplicativo

Este artigo fornece diretrizes de como identificar e investigar ataques de consentimento de aplicativo, proteger informações e minimizar outros riscos.

Este artigo inclui as seções a seguir:

• 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.
• Lista de verificação: contém uma lista de tarefas para cada uma das etapas no fluxograma. Essa lista de verificação pode ser útil em ambientes altamente regulamentados para verificar as etapas adotadas ou simplesmente como um controle de qualidade do seu trabalho.
• Etapas de investigação: esta seção inclui diretrizes passo a passo detalhadas desta investigação específica.
• Recuperação: contém etapas gerais sobre a recuperação e a mitigação após um ataque de fornecimento de consentimento de aplicativo ilícito.
• Referências: contém mais materiais de leitura e referência.

Pré-requisitos

Aqui estão as definições e configurações gerais que você deve concluir ao executar uma investigação de fornecimentos de consentimento de aplicativo. Antes de iniciar a investigação, certifique-se de ler sobre os tipos de permissões de consentimento explicados em Tipos de permissão de consentimento.

Dados do cliente

Para iniciar o processo de investigação, você precisa dos seguintes dados:

• Detalhes dos IoCs (indicadores de comprometimento)
• A data e a hora em que você percebeu o incidente
• Intervalo de datas
• Número de contas comprometidas
• Nome das contas comprometidas
• Funções da conta comprometida
• As contas são altamente privilegiadas (Microsoft Exchange e SharePoint em GA)?
• Há algum aplicativo empresarial relacionado ao incidente?
• Algum usuário relatou que algum aplicativo solicitou permissões para dados em nome dele?

Requisitos do sistema

Conclua as seguintes instalações e requisitos de configuração verificando se:

• O módulo do AzureAD PowerShell está instalado.
• Você tem direitos de Administrador Global no locatário em que o script é executado.
• Você recebeu a função de administrador local no computador que você usa para executar os scripts.

Instalar o módulo AzureAD

Use este comando para instalar o módulo AzureAD.

Install-Module -Name AzureAD -Verbose

Instalar o módulo MSOnline do PowerShell

1. Execute o aplicativo Windows PowerShell com privilégios elevados (execute-o como administrador).

2. Execute este comando para permitir que o PowerShell execute scripts assinados.

   Set-ExecutionPolicy RemoteSigned
   

3. Instale o módulo MSOnline com este comando.

   Install-Module -Name MSOnline -Verbose
   

   Observação

   Se for solicitado que você instale os módulos de um repositório não confiável, digite Y e pressione Enter.

Baixar o script AzureADPSPermissions do GitHub

1. Baixar o script Get-AzureADPSPermissions.ps1 do GitHub em uma pasta que você usa para executar o script. O arquivo de saída "permissions.csv" também fica gravado nessa mesma pasta.

2. Abra uma instância do PowerShell como administrador e abra a pasta na qual você salvou o script.

3. Conecte-se com o diretório usando o cmdlet Connect-AzureAD. Veja um exemplo.

   Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"
   

4. Execute este comando do PowerShell.

   Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation
   

   Desconecte a sessão do AzureAD com este comando.

   Disconnect-AzureAD
   

Terminologias de consentimento

O que são fornecimentos de consentimento de aplicativo?

Consentimento é o processo de conceder autorização a um aplicativo para acessar recursos protegidos em nome dos usuários. Um administrador ou usuário pode ser solicitado a dar consentimento para permitir acesso aos dados dele ou da organização.

Um aplicativo recebe acesso a dados de um usuário específico ou de toda a organização. Os invasores podem usar indevidamente esses consentimentos para obter persistência no ambiente e acessar dados confidenciais. Esses tipos de ataques são chamados de fornecimentos de consentimento ilícitos, que podem ocorrer por um email de phishing, uma conta de usuário comprometida por pulverização de senha ou quando um invasor registra um aplicativo como um usuário legítimo. Nos cenários em que uma conta do administrador é comprometida, o registro e o fornecimento de consentimento ocorrem para todo o locatário e não apenas para um usuário.

Antes que um aplicativo possa acessar os dados da sua organização, um usuário precisa conceder permissões ao aplicativo para isso. Permissões diferentes permitem diferentes níveis de acesso. Por padrão, todos os usuários têm permissão para consentir nos aplicativos em relação a permissões que não exijam o consentimento do administrador. Por exemplo, por padrão, um usuário pode permitir que um aplicativo acesse a caixa de correio dele, mas não pode permitir que um aplicativo tenha acesso irrestrito de leitura e gravação em todos os arquivos da organização.

Funções que podem fornecer consentimento em nome da organização

Para poder conceder consentimento de administrador em todo o locatário, você deve entrar com pelo menos uma das seguintes funções:

• Administrador de Aplicativos
• Administrador de Aplicativos de Nuvem

Tipos de consentimento

• Administrador – Indica que o consentimento foi fornecido pelo administrador (em nome da organização)
• Usuário individual: indica que o consentimento foi fornecido pelo usuário e só permite o acesso às informações desse usuário
• Valores aceitos
  • AllPrincipals – Fornecido por um administrador para toda a locação
  • Principal – Fornecido pelo usuário individual somente para dados relacionados a essa conta

Consentimentos e permissões

Na realidade, a experiência do usuário de dar consentimento varia de acordo com as políticas definidas no locatário do usuário, o escopo (ou a função) do usuário da autoridade e o tipo de permissões solicitado pelo aplicativo cliente. Isso significa que os desenvolvedores de aplicativos e administradores de locatários têm algum controle sobre a experiência de consentimento. Os administradores têm a flexibilidade de definir e desativar políticas em um locatário ou aplicativo para controlar a experiência de consentimento no locatário. Os desenvolvedores de aplicativos podem determinar que tipos de permissões são solicitados e se querem orientar os usuários por meio do fluxo de consentimento do usuário ou do fluxo de consentimento do administrador.

• Fluxo de consentimento do usuário – Quando um desenvolvedor de aplicativos direciona os usuários para o ponto de extremidade da autorização com a intenção de registrar o consentimento somente para o usuário atual.

• Fluxo de consentimento do administrador – Quando um desenvolvedor de aplicativos direciona os usuários para o ponto de extremidade de consentimento do administrador com a intenção registrar o consentimento para o locatário inteiro. 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.

Permissões delegadas versus permissões de aplicativo

As permissões delegadas são usadas por aplicativos que têm um usuário conectado presente e podem ter consentimentos aplicados pelo administrador ou usuário.

As permissões de aplicativo são usadas por aplicativos que são executados sem um usuário conectado presente. Por exemplo, aplicativos executados como serviços ou daemons em segundo plano. As permissões de aplicativo só podem ser concedidas por um administrador.

Para saber mais, veja:

• Fluxo de trabalho de consentimento do administrador de aprovação de administrador para aplicativos específicos
• Programa de verificação de editor
• Configurar como os usuários finais dão consentimento para aplicativos

Como classificar permissões suspeitas

Há no mínimo milhares de permissões no sistema e não é possível listar ou analisar todas elas. A lista a seguir demonstra as permissões que geralmente são usadas indevidamente e outras que podem causar um impacto catastrófico quando isso ocorre.

Em geral, a Microsoft observou que as permissões “raiz” delegadas a seguir (aplicativo + usuário) são usadas indevidamente em ataques de phishing de consentimento. A raiz é igual ao nível máximo. Por exemplo, Contacts.* significa incluir todas as permutações delegadas das permissões de Contatos: Contacts.Read, Contacts.ReadWrite, Contacts.Read.Shared e Contacts.ReadWrite.Shared.

1. Mail.* (inclui Mail.Send*, mas não Mail.ReadBasic*)
2. Contatos. *
3. MailboxSettings.*
4. People.*
5. Files.*
6. Notes.*
7. Directory.AccessAsUser.All
8. User_Impersonation

As sete primeiras permissões na lista acima são para o Microsoft Graph e os equivalentes da API “herdada”, como a API do Graph do Azure AD (Azure Active Directory) e a API REST do Outlook. A oitava permissão é para o ARM (Azure Resource Manager) e também pode ser perigosa em qualquer API que exponha dados confidenciais com esse escopo amplo de representação.

Com base nas observações da equipe de Resposta a Incidentes da Microsoft, os invasores usam uma combinação das seis primeiras permissões em 99% dos ataques de phishing de consentimento. A maioria das pessoas não acha que a versão delegada de Mail.Read ou Files.Read é uma permissão de alto risco. No entanto, os ataques geralmente são generalizados direcionados aos usuários finais, em vez de ataques de spear phishing contra administradores que realmente podem dar consentimento para permissões perigosas. É recomendado restringir os aplicativos com essas permissões de impacto de nível “crítico”. Mesmo que o aplicativo não tenha má intenção, se um ator mal-intencionado quiser comprometer a identidade do aplicativo, toda a organização poderá estar em risco.

Para as permissões de impacto de risco mais alto, comece aqui:

• Versões de permissão de aplicativo (AppOnly/AppRole) de todas as permissões acima, quando aplicável

Versões delegadas e AppOnly das seguintes permissões:

• Application.ReadWrite.All
• Directory.ReadWrite.All
• Domain.ReadWrite.All*
• EduRoster.ReadWrite.All*
• Group.ReadWrite.All
• Member.Read.Hidden*
• RoleManagement.ReadWrite.Directory
• User.ReadWrite.All*
• User.ManageCreds.All
• Todas as outras permissões AppOnly que permitem acesso de gravação

Para a lista de permissões de impacto de risco mais baixo, comece aqui:

• User.Read
• User.ReadBasic.All
• Open_id
• Email
• Perfil
• Offline_access (somente se emparelhada com outras permissões nessa lista de “riscos mais baixos”)

Como ver as permissões

1. Para ver as permissões, navegue até a tela Registro no aplicativo empresarial.

   

2. Selecione Ver as permissões da API.

   

3. Selecione Adicionar uma permissão e a tela a seguir será exibida.

   

4. Selecione Microsoft Graph para ver os diferentes tipos de permissões.

   

5. Selecione o tipo de permissões que o aplicativo registrado está usando: Permissões delegadas ou Permissões de aplicativo. Na imagem acima, o tipo Permissões de aplicativo está selecionado.

6. Você pode procurar uma das permissões de impacto de alto risco, como EduRoster.

   

7. Selecione EduRoster e expanda as permissões.

   

8. Agora você pode atribuir ou examinar essas permissões.

   Para obter mais informações, Permissões do Graph.

Workflow

[]

Também é possível:

• Baixe os fluxos de trabalho de guia estratégico de resposta a concessão de consentimento de aplicativo e outros incidentes no formato PDF.
• Baixe os fluxos de trabalho de guia estratégico de resposta a concessão de consentimento de aplicativo e outros incidentes no formato Visio.

Lista de Verificação

Use esta lista de verificação para executar a validação de fornecimento de consentimento de aplicativo.

• IoC (indicadores de comprometimento)

  Verifique os seguintes IoC (indicadores de comprometimento):

  • Quando você percebeu o incidente?
  • Intervalo de datas do incidente (há quanto tempo ele começou?)
  • Número de contas comprometidas
  • Nomes das contas comprometidas
  • Funções das contas comprometidas
  • As contas comprometidas são altamente privilegiadas, um usuário padrão ou uma combinação

• Funções

  Você precisa receber estas funções:

  • Função Administrador local no computador que executa o script

• Configuração do PowerShell

  Configure o ambiente do PowerShell com as etapas a seguir:

  1. Instale o módulo do PowerShell do Azure AD.
  2. Execute o aplicativo Windows PowerShell com privilégios elevados. (Execute como administrador).
  3. Configure o PowerShell para executar scripts assinados.
  4. Baixe o script Get-AzureADPSPermissions.ps1.

• Gatilhos de investigação

  • Comprometimento da conta
  • Configurações de consentimento do aplicativo modificadas no locatário
  • Motivo do status do evento de alerta/auditoria "aplicativo suspeito" detectado
  • Aplicativos de aparência ímpar observados

Você também pode baixar as listas de verificação do guia estratégico de concessão de consentimento de aplicativo e outros incidentes no formato Excel.

Etapas de investigação

Você pode usar os dois métodos seguintes para investigar os fornecimentos de consentimento de aplicativo:

• Portal do Azure
• Script do PowerShell

Método 1 – Usando o portal do Azure

Você pode usar o Centro de administração do Microsoft Entra para localizar aplicativos que usuários individuais concederam permissões.

1. Entre no Portal do Azure como administrador.
2. Selecione o ícone Microsoft Entra ID.
3. Selecione Usuários.
4. Selecione o usuário que você deseja examinar.
5. Selecione Aplicativos.
6. Veja a lista de aplicativos atribuídos ao usuário e quais permissões esses aplicativos têm.

Método 2 – Usando o PowerShell

Há várias ferramentas do PowerShell que você pode usar para investigar os fornecimentos de consentimento ilícitos, como:

• Ferramenta HAWK
• Módulo AzureAD de resposta a incidente
• O script Get-AzureADPSPermissions.ps1 do GitHub

O PowerShell é a ferramenta mais fácil e não exige nenhuma modificação na locação. Vamos basear nossa investigação na documentação pública do ataque de fornecimento de consentimento ilícito.

Execute Get-AzureADPSPermissions.ps1, para exportar todos os fornecimentos de consentimento do OAuth e os aplicativos OAuth de todos os usuários na locação para um arquivo .csv. Confira a seção Pré-requisitos para baixar e executar o script Get-AzureADPSPermissions.

1. Abra uma instância do PowerShell como administrador e abra a pasta na qual você salvou o script.

2. Conecte-se com o diretório usando o comando Connect-AzureAD a seguir. Veja um exemplo.

   Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"
   

3. Execute este comando do PowerShell.

   Get-AzureADPSPermissions.ps1 | Export-csv c:\temp\consentgrants\Permissions.csv -NoTypeInformation
   

4. Quando o script for concluído, desconecte a sessão do Microsoft Entra com este comando.

    Disconnect-AzureAD
   

   Observação

   O script pode levar horas para ser concluído, dependendo do tamanho e das permissões configuradas, bem como da conexão.

5. O script cria um arquivo chamado Permissions.csv.

6. Abra o arquivo, filtre ou formate os dados em uma tabela e salve-os como um arquivo .xlxs.

   Os cabeçalhos de coluna da saída são mostrados nesta imagem.

   

7. Na coluna ConsentType (G), procure o valor AllPrinciples. A permissão AllPrincipals permite que o aplicativo cliente acesse o conteúdo de todos na locação. Os aplicativos nativos do Microsoft 365 precisam dessa permissão para funcionar corretamente. Todos os aplicativos que não são da Microsoft com essa permissão devem ser examinados com atenção.

8. Na coluna Permission (F), examine as permissões que cada aplicativo delegado tem. Procure a permissão de leitura e gravação ou permissão *. Todos, e revise essas permissões cuidadosamente porque elas podem não ser apropriadas.

   Observação

   Examine os usuários específicos que receberam consentimentos. Se há usuários de perfil superior ou de alto impacto com consentimentos inadequados, investigue mais.

9. Na coluna ClientDisplayName (C), procure aplicativos que pareçam suspeitos, como:

   • Aplicativos com nomes incorretos

   • Nomes incomuns ou sem graça

   • Nomes que parecem de hacker. Você precisa examinar esses nomes com atenção.

Saída de exemplo: AllPrincipals e ler e gravar tudo. Os aplicativos podem não ter nada suspeito como nomes combinados e estão usando o Microsoft Graph. No entanto, execute a pesquisa e determine a finalidade dos aplicativos e as permissões reais que eles têm no locatário, como é mostrado neste exemplo.

Aqui estão algumas dicas úteis para examinar as investigações de ISP (política de segurança de informações):

• ReplyURL/RedirectURL
  • Procurar URLs suspeitas
• A URL está hospedada em um domínio suspeito?
  • Ela está comprometida?
  • O domínio foi registrado recentemente?
  • É um domínio temporário?
• Há um link dos termos de serviço ou do contrato de serviço no registro de aplicativo?
• O conteúdo é exclusivo e específico do aplicativo/editor?
• O locatário que registrou o aplicativo foi criado recentemente ou está comprometido (por exemplo, o aplicativo foi registrado por um usuário em risco)?

Detalhes do ataque de fornecimento de consentimento

Técnicas de ataque

Embora os ataques possam variar, as principais técnicas de ataque são:

• Um invasor registra um aplicativo em um provedor do OAuth 2.0, como o Microsoft Entra ID.

• Os aplicativos são configurados de maneira que os faz parecer legítimos. Por exemplo, os invasores podem usar o nome de um produto popular disponível no mesmo ecossistema.

• O invasor recebe um link diretamente dos usuários, o que pode ser feito por phishing baseado em email convencional, pelo comprometimento de um site que não é mal-intencionado ou com outras técnicas.

• O usuário seleciona o link e recebe uma solicitação de consentimento autêntico solicitando que ele conceda permissões a dados ao aplicativo mal-intencionado.

• Se o usuário selecionar ‘Aceitar’, ele concede permissões ao aplicativo para acessar dados confidenciais.

• O aplicativo obtém um código de autorização, com o qual resgata um token de acesso e, possivelmente, um token de atualização.

• O token de acesso é usado para fazer chamadas à API em nome do usuário.

• Quando o usuário aceita isso, o invasor pode obter acesso aos emails do usuário, às regras de encaminhamento, aos arquivos, aos contatos, às anotações, ao perfil e a outros dados e recursos confidenciais.

  

Como encontrar sinais de um ataque

1. No portal do Microsoft 365 Defender, em https://security.microsoft.com, acesse Auditar. Ou vá diretamente para a página Auditoria e use https://security.microsoft.com/auditlogsearch.

2. Na página Auditoria, pesquise todas as atividades e todos os usuários, insira a data de início e a data de término, se necessário, e selecione Pesquisar.

   

3. Selecione Filtrar os resultados e, no campo Atividade, insira Consentir para aplicativo.

   

4. Se você tem alguma atividade em consentir com o fornecimento, continue para a próxima etapa.

5. Selecione o resultado para ver os detalhes da atividade. Selecione Mais Informações para obter detalhes da atividade.

6. Verifique se IsAdminContent está definido como ‘True’.

   Observação

   Esse processo pode levar de 30 minutos a 24 horas para que a entrada de log de auditoria correspondente seja exibida nos resultados da pesquisa depois que um evento ocorre.

   O período em que um registro de auditoria fica retido e pesquisável no log de auditoria depende da sua assinatura do Microsoft 365 e, especificamente, do tipo da licença atribuída a um usuário específico. Se esse valor for true, ele indica que alguém pode ter concedido amplo acesso aos dados. Se isso for inesperado, tome medidas imediatas para confirmar um ataque.

Como confirmar um ataque?

Se você tem uma ou mais instâncias dos IoCs listados anteriormente, continue a investigação para confirmar se o ataque realmente ocorreu.

Inventariar os aplicativos com acesso na organização

Você pode inventariar os aplicativos dos usuários usando o centrode administração do Microsoft Entra, o PowerShell ou solicitar que os usuários enumerem individualmente o acesso a aplicativos.

• Use o centro de administração do Microsoft Entra para inventariar aplicativos e suas permissões. Esse método é completo, mas você só pode verificar um usuário de cada vez, o que pode demorar quando você precisa verificar as permissões de vários usuários.
• Usar o PowerShell para inventariar os aplicativos e as permissões deles. Esse método é o mais rápido e mais completo, com a menor quantidade de sobrecarga.
• Incentive os usuários a verificar individualmente os aplicativos e as permissões e relatar os resultados aos administradores para correção.

Inventariar os aplicativos atribuídos aos usuários

Você pode usar o Centro de administração do Microsoft Entra para ver a lista de aplicativos aos quais usuários individuais concederam permissões.

1. Entre no portal do Azure com direitos administrativos.
2. Selecione o ícone Microsoft Entra ID.
3. Selecione Usuários.
4. Selecione o usuário que você deseja examinar.
5. Selecione Aplicativos.

Veja a lista de aplicativos atribuídos ao usuário e as permissões concedidas a esses aplicativos.

Determinar o escopo do ataque

Depois de concluir o inventário do acesso de aplicativos, examine o log de auditoria para determinar o escopo completo da violação. Pesquise os usuários afetados, os períodos em que o aplicativo ilícito teve acesso à organização e as permissões que o aplicativo tinha. Você pode pesquisar o log de auditoria nos portais de conformidade do Microsoft 365 Security e Microsoft Purview.

Como evitar ataques e mitigar riscos?

• Faça periodicamente a auditoria dos aplicativos e das permissões concedidas na organização para garantir que nenhum aplicativo suspeito ou desnecessário tenha recebido acesso a dados.

• Revise, detecte e corrija concessões de consentimento ilícitas no Office 365. para obter mais práticas recomendadas e proteções contra aplicativos suspeitos que solicitam o consentimento do OAuth.

Se sua organização tem a licença apropriada:

• Use outros mais recursos de auditoria do aplicativo OAuth no Microsoft Defender para Aplicativos de Nuvem.
• Use as Pastas de Trabalho do Azure Monitor para monitorar as permissões e as atividades relacionadas a consentimento. A pasta de trabalho Insights de Consentimento oferece uma exibição de aplicativos por número de solicitações de consentimento com falha. Essa exibição pode ser útil para priorizar os aplicativos a serem examinados pelos administradores para que eles decidam se o consentimento do administrador deve ser fornecido.

Como interromper e corrigir um ataque de fornecimento de consentimento ilícito?

Depois de identificar um aplicativo com permissões ilícitas, desabilite imediatamente o aplicativo seguindo as instruções em Desabilitar um aplicativo. Em seguida, contate o Suporte da Microsoft para relatar o aplicativo mal-intencionado.

Depois que um aplicativo é desabilitado no Microsoft Entra, ele não pode obter novos tokens para acessar dados e outros usuários não podem entrar ou conceder consentimento ao aplicativo.

Defesas recomendadas

Etapas para proteger a organização

Há vários tipos de ataque de consentimento; estas defesas recomendadas mitigam todos os tipos de ataques, principalmente o phishing de consentimento, no qual os invasores enganam os usuários para que eles permitam que um aplicativo mal-intencionado acesse dados confidenciais ou outros recursos. Em vez de tentar roubar a senha do usuário, o invasor tenta obter permissão para que um aplicativo controlado por ele acesse dados importantes.

Como uma ajuda para evitar que ataques de consentimento afetem o Microsoft Entra ID e o Office 365, confira as seguintes recomendações:

Definir políticas

• Essa configuração tem implicações para o usuário e talvez não ser aplicável a um determinado ambiente. Se você vai permitir consentimentos, certifique-se de que os administradores aprovem as solicitações.

• Permita o consentimento para aplicativos somente de editores verificados e tipos específicos de permissões classificados como baixo impacto.

  Observação

  As recomendações acima são sugeridas com base nas configurações mais ideais e seguras. No entanto, como a segurança é um equilíbrio entre as funcionalidades e as operações, as configurações mais seguras podem causar mais sobrecarga para os administradores. É melhor tomar uma decisão depois de consultar os administradores.

  Configurar o consentimento de step-up com base em risco – Opção habilitada por padrão quando o consentimento do usuário com o fornecimento está habilitado

• O consentimento de step-up baseado em risco ajuda a reduzir a exposição do usuário a aplicativos mal-intencionados que fazem solicitações de consentimento ilícitas. Se a Microsoft detectar uma solicitação arriscada de consentimento ao usuário final, a solicitação exige um "step-up" para o consentimento do administrador. Essa capacidade é habilitada por padrão, mas só resulta em uma alteração de comportamento quando o consentimento do usuário final estiver habilitado.

• Quando uma solicitação de consentimento arriscado for detectada, a solicitação de consentimento exibe uma mensagem indicando que a aprovação do administrador é necessária. Quando o fluxo de trabalho de solicitação de consentimento do administrador está habilitado, o usuário pode enviar a solicitação ao administrador para exame adicional diretamente da solicitação de consentimento. Quando habilitado, a seguinte mensagem é exibida:

  AADSTS90094: <clientAppDisplayName> precisa de permissão para acessar recursos em sua organização que somente um administrador pode conceder. Peça a um administrador para conceder permissão ao aplicativo antes de poder usá-lo. Nesse caso, um evento de auditoria também será registrado com a categoria "ApplicationManagement" Tipo de atividade "Consentimento para aplicativo" e a razão do status "Aplicativo arriscado detectado".

Instrua os desenvolvedores de aplicativos a seguir o ecossistema de aplicativos confiável. Para ajudar os desenvolvedores a criar integrações seguras e de alta qualidade, também estamos anunciando a versão prévia pública do Assistente de Integração nos registros de aplicativo do Microsoft Entra.

• O Assistente de Integração analisa o registro de aplicativo e avalia-o em relação a um conjunto de práticas recomendadas de segurança.
• O Assistente de Integração realça as práticas recomendadas que são relevantes durante cada fase do ciclo de vida da integração, desde o desenvolvimento até o monitoramento, e garante que cada estágio esteja configurado corretamente.
• Ele facilita seu trabalho, esteja você integrando seu primeiro aplicativo ou buscando aprimorar suas habilidades de especialista.

Instrua sua organização sobre táticas de consentimento (táticas de phishing, consentimentos do administrador e do usuário):

• Verifique se há erros ortográficos e gramaticais. Se uma mensagem de email ou a tela de consentimento do aplicativo tem erros ortográficos e gramaticais, provavelmente se trata de um aplicativo suspeito.
• Fique atento a nomes de aplicativos e URLs de domínio. Os invasores gostam de falsificar nomes de aplicativos para parecer que o aplicativo ou a empresa é legítima, fazendo com que você dê consentimento a um aplicativo mal-intencionado.
• Faça um reconhecimento do nome do aplicativo e da URL do domínio antes de consentir com um aplicativo.

Promover e permitir acesso a aplicativos confiáveis

• Promova o uso de aplicativos cujos editores já foram verificados. A verificação do editor ajuda os administradores e os usuários finais a entender a autenticidade dos desenvolvedores de aplicativos. Mais de 660 aplicativos de 390 editores já foram verificados até o momento.
• Configure políticas de consentimento de aplicativo permitindo que os usuários consintam apenas com aplicativos específicos nos quais você confia, como aplicativos desenvolvidos pela sua organização ou de editores verificados.
• Instrua sua organização sobre como nossa estrutura de permissões e consentimento funciona.
• Entenda os dados e as permissões que um aplicativo está solicitando e como as permissões e o consentimento funcionam na nossa plataforma.
• Verifique se os administradores sabem como gerenciar e avaliar as solicitações de consentimento.

Audite os aplicativos e as permissões consentidas na organização para garantir que os aplicativos usados acessem apenas os dados necessários e sigam os princípios de privilégios mínimos.

Mitigações

• Instruir o cliente e oferecer treinamento sobre como reconhecer e proteger os fornecimentos de consentimento de aplicativo
• Reforçar o processo de fornecimento de consentimento de aplicativo com uma política organizacional e controles técnicos
• Configurar a opção Criar agendamento para examinar os aplicativos Consentidos
• Você pode usar o PowerShell para desabilitar aplicativos suspeitos ou mal-intencionados desabilitando o aplicativo

Conteúdo relacionado

• Como se proteger contra ataques de aplicativos de força de trabalho remota
• Como promover um ecossistema de aplicativos seguro e confiável
• Investigar aplicativos OAuth suspeitos
• Gerenciar o consentimento para aplicativos e avaliar solicitações de consentimento
• Desabilitar as entradas de usuário em um aplicativo empresarial no Microsoft Entra ID
• Entenda as permissões e a estrutura de consentimento na plataforma de identidade da Microsoft.
• Entenda a diferença entre permissões delegadas e permissões de aplicativo.
• Configurar como os usuários finais concordam com os aplicativos
• Aplicativo inesperado em minha lista de aplicativos
• Detectar e corrigir fornecimentos de consentimento ilícitos
• Como e por quê os Aplicativos do Microsoft Entra são adicionados
• Objetos de entidade de serviço e aplicativo no Microsoft Entra ID
• Documentador da configuração do Microsoft Entra
• Gerenciar o consentimento para aplicativos e avaliar solicitações de consentimento
• Get-AzureADServicePrincipal
• Build 2020: promovendo um ecossistema de aplicativos seguro e confiável para todos os usuários
• Configurar o fluxo de trabalho de consentimento do administrador
• Os administradores devem avaliar todas as solicitações de consentimento cuidadosamente antes de aprovar uma solicitação.
• Registro de aplicativo versus aplicativos empresariais
• Permissões
• KrebsOnSecurity sobre o phishing de AppConsent

Mais guias estratégicos de resposta a incidente

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

• Phishing
• Pulverização de senha

Recursos de resposta a incidentes

• Visão geral dos produtos e recursos de segurança da Microsoft para analistas novos e experientes na função
• Planejamento do seu SOC (Centro de Operações de Segurança)
• Resposta a incidentes do Microsoft Defender XDR
• Microsoft Defender para Nuvem (Azure)
• Resposta a incidentes do Microsoft Sentinel
• O guia da equipe de Resposta a Incidentes da Microsoft compartilha as melhores práticas para equipes de segurança e líderes
• Os guias de Resposta a Incidentes da Microsoft ajudam as equipes de segurança a analisar atividades suspeitas