Detectando backdoors do Microsoft 365 e do Azure Active Directory

Views: 179
0 0
Read Time:15 Minute, 13 Second

Mandiant viu um aumento nos incidentes envolvendo o Microsoft 365 (M365) e o Azure Active Directory (Azure AD). A maioria desses incidentes é resultado de um e-mail de phishing coagindo um usuário a inserir suas credenciais usadas para acessar o M365 em um site de phishing. Outros incidentes foram resultado de pulverização de senhas, recheio de senha ou simples tentativas de força bruta contra inquilinos M365. Em quase todos esses incidentes, o usuário ou conta não estava protegido pela autenticação multifatorial (MFA).

Esses ataques oportunistas são certamente a forma mais comum de compromisso para M365 e Azure AD, e geralmente são o vetor inicial para estabelecer persistência. Durante ambos os compromissos de resposta a incidentes (IR) e avaliações proativas de nuvem, muitas vezes somos perguntados:

  • Quais são alguns outros tipos de ataques que Mandiant está vendo contra M365 e Azure AD?
  • É possível que um compromisso no local se mude “verticalmente” para M365 e Azure AD?
  • Se uma conta de administrador global estiver comprometida, é possível manter a persistência mesmo após a conta comprometida ter sido detectada, ocorreu uma redefinição de senha e o MFA foi aplicado?

Módulo PowerShell AADInternals

Em alguns incidentes, o Mandiant testemunhou atacantes utilizando um módulo PowerShell chamado AADInternals, que pode permitir que um invasor se mova verticalmente de locais para Azure AD, estabeleça backdoors, roube senhas, gere tokens de segurança do usuário e contorne proteções MFA. Este módulo PowerShell permitiu que os atacantes mantivessem a persistência no inquilino mesmo após os esforços iniciais de erradicação terem sido realizados.

Para ver este módulo em ação e entender como ele funciona, a apresentação psconfeu 2020 do Dr. Nestori Syynimaa, Abusando do Diretório Ativo do Azure: Quem você gostariade ser hoje?

Para detectar o uso de AADInternals, é importante entender como alguns desses ataques funcionam. Uma vez estabelecido um entendimento, o uso anormal pode ser detectado através de uma combinação de análise de log e indicadores baseados em host.

Backdoor 1: Abusando da Autenticação de Passagem

Requisitos do atacante

  • Acesso administrativo local a um servidor executando autenticação de passagem

Ou

  • Credenciais de administradorglo-de-m365

O módulo AADInternals PowerShell contém uma função chamada Install-AADIntPTASPY. A função funciona inserindo-se como um homem-no-meio dentro do processo de Autenticação de Passagem (PTA) que ocorre entre o Azure AD e o servidor executando o Agente PTA no ambiente local. Normalmente, o Agente PTA é executado no mesmo servidor local que o Azure AD Connect (AAD Connect).

Quando o PTA é ativado, cada logon que ocorre contra o Azure AD é redirecionado para o Agente PTA no local. O Agente PTA pergunta a um controlador de domínio do Active Directory no local se uma senha é válida para uma conta autenticada. Se válido, o Agente PTA responde ao Azure AD para conceder acesso ao solicitante. A Figura 1 fornece o fluxo de trabalho da Autenticação de Passagem e onde os AADInternals podem interceptar a solicitação.


Figura 1: Fluxo de trabalho de autenticação de passagem

Uma vez que a função esteja em execução, todas as tentativas de PTA contra o Azure AD serão interceptadas pelo módulo AADIntPTASpy instalado. O módulo registrará a tentativa de senha do usuário e responderá ao Azure AD em nome do Agente PTA. Esta resposta aconselha o Azure AD que a tentativa de senha foi válida e concede ao usuário acesso à nuvem, mesmo que a senha esteja incorreta. Se um invasor tiver implantado o AADIntPTASpy,ele poderá fazer login como qualquer usuário que tente autenticar usando PTA — e terá acesso.

Além disso, todas as tentativas de senha que são registradas pelo módulo AADIntPTASpy são registradas dentro de um arquivo de log no servidor (Localização padrão: C:\PTASpy\PTASPy.csv). A Figura 2 mostra como o arquivo de registro pode ser decodificado para revelar a senha de um usuário em cleartext.


Figura 2: Senhas decodificadas PTASpy.csv

Não só essa função permitirá que um invasor faça login como qualquer usuário que autentica via PTA, mas também atuará como um repositório para coletar senhas de usuário que estão fazendo login no Azure AD. Isso pode permitir que um invasor gire seu ataque para outras áreas da rede — ou use essas credenciais contra outros portais acessíveis à Internet que possam aproveitar a autenticação de um fator único (por exemplo, gateway VPN).

Um invasor pode usar este módulo de duas maneiras:

Método 1: Compromisso on-premises

Um invasor teve acesso a um domínio local e é capaz de mover-se lateralmente para o AADConnect / PTA Agent Server. A partir deste servidor, um invasor pode potencialmente aproveitar o módulo AADInternals PowerShell e invocar a função Install-AADIntPTASpy.

Método 2: Compromisso de nuvem

Se um invasor comprometeu com sucesso uma conta de administração global do AzureAD, um ataque pode ser conduzido a partir da própria infraestrutura de um invasor. Um invasor pode instalar um Agente PTA em um servidor que gerencia e registrar o agente usando a conta de administrador global comprometida (Figura 3).


Figura 3: Portal Azure AD — agentes de autenticação de passagem registrados

Uma vez registrado no Azure AD, o servidor desonesto começará a interceptar e autorizar todas as tentativas de login. Assim como no Método 1, este servidor também pode ser usado para coletar credenciais válidas.

Backdoor 2: Federação de Identidade Abusando

Requisitos do atacante

  • Acesso administrativo local a AD e servidor executando Serviços da Federação de Diretório Ativo

Ou

  • Credenciais de administradorglo-de-m365

Outro método de autenticação para M365 é através do uso dos serviços da federação. Quando um domínio M365 é configurado como um domínio federado, uma confiança é configurada entre m365 e um provedor de identificação externa. Em muitos casos, essa confiança é estabelecida com um servidor ADFS (Active Directory Federation Services, serviços da Federação ativa) para um domínio do Active Directory no local.

Uma vez estabelecida uma confiança, quando um usuário entra no M365 usando um domínio federado, sua solicitação é redirecionada para o provedor de identificação externa (ADFS) onde sua autenticação é validada (Figura 4). Uma vez validado, o servidor ADFS fornece ao usuário um token de segurança. Este token é então confiável pelo M365 e concede o acesso à plataforma.


Figura 4: Fluxo de trabalho de entrada de entrada da Microsoft 365 Federation

AADInternals tem uma função PowerShell para criar tokens de segurança, o que imita o processo de autenticação do ADFS. Ao fornecer à função um UserPrincipalName válido, ID imutável e IssuerURI, um invasor pode gerar um token de segurança como qualquer usuário do inquilino. O que é ainda mais preocupante é que uma vez que este token de segurança é gerado, isso pode permitir que um invasor contorne mfa.

Como no Backdoor 1, este ataque pode ser realizado a partir de um ambiente no local comprometido ou a partir da própria infraestrutura do invasor.

Método 1: Compromisso on-premises

Uma vez que um invasor tenha acesso a um domínio local com acesso elevado, ele pode começar a coletar as informações necessárias para criar seus próprios tokens de segurança para backdoor em M365 como qualquer usuário. Um invasor exigirá:

  • Um UserPrincipalName válido e imutável.
    • Ambos os atributos podem ser retirados do domínio active Directory no local.
  • Emissoruri do servidor ADFS e certificado de assinatura do ADFS.
    • Isso pode ser obtido a partir de um servidor ADFS quando conectado diretamente ao servidor ou consultando remotamente o servidor através de uma conta privilegiada.

Uma vez que um invasor tenha coletado as informações necessárias, usando o comando AADInternals Open-AADIntOffice365Portal, um token de segurança para o usuário pode ser gerado concedendo um acesso de invasor ao M365 (Figura 5).


Figura 5: AADInternals Open-AADIntOffice365 Comandoportal

Método 2: Compromisso de nuvem

Se um invasor tiver uma conta de administrador global M365 comprometida, usando sua própria infraestrutura, um invasor pode usar seu acesso administrativo para coletar informações do usuário e reconfigurar o inquilino para estabelecer seu backdoor. Neste método, um invasor exigirá:

  • Um UserPrincipalName válido e ImmutableId válido.
    • A Figura 6 mostra como o comando Get-MsolUser pode obter o ImmutableId de um usuário do Azure AD.


Figura 6: Get-MsolUser — liste o usuário UPN & ImmutableId

  • EmissorURI
    • Isso pode ser obtido convertendo um domínio gerenciado em um domínio federado. As figuras 7 a 10 mostram como o comando AADInternals ConvertTo-AADIntBackdoor (Figura 8) pode ser usado para permitir que o invasor registre seu próprio Emissor PARA um domínio federado.


Figura 7: Get-msoldomain — lista de domínios registrados e autenticação


Figure 8: ConvertTo-AADIntBackdoor—convert domain to federated authentication


Figure 9: Changed authentication method


Figure 10: Azure AD Portal registered domains

Note: To not interrupt production and authentication with an existing federated domain (and to remain undetected), an attacker may opt to register a new domain with the tenant.


Figure 11: AADInternals Open-AADIntOffice365Portal Command using new Federated domain

Once an attacker has properly configured the tenant, using the ImmutableId of any user, a security token can be generated by executing the Open-AADIntOffice365Portal command (Figure 11). This will allow an attacker to login as that user without the need for a valid certificate or a legitimate IssuerURI.

Fortunately for defenders, this method will generate a number of events in the unified audit log, which can be leveraged for monitoring and alerting.

Mitigation and Detection

Once persistence is established, it can be extremely difficult to detect login activity that is utilizing one of the previously described methods. In lieu of this, it is recommended to monitor and alert on M365 unified audit logs and Azure AD sign-in activity to detect anomalous activity.

Detection in FireEye Helix

Being that Mandiant has seen this methodology being used in the wild, we felt it was necessary to build these detections into our FireEye Helix security platform. Helix engineers have created sever new detection rules that monitor for detectable activity of an attacker making use of the AADInternals PowerShell module.

The following five rules will monitor a server’s event logs and alert upon the installation and usage of the AADInternals PowerShell module (Figure 12). The detection of these activities could be high fidelity alerts that an attacker is preparing to configure backdoors into M365 and Azure AD environments.


Figura 12: Regras da Helix AADInternals

Se um invasor tiver configurado com sucesso um backdoor usando AADInternals, a Helix alertará sobre os seguintes eventos registrados no registro de auditoria unificado do Office 365 e no Registro de Atividades do Azure como indicação de um possível evento (Figura 13 e Figura 14). É importante notar que esses alertas podem ser acionados em atividades legítimas de administrador. Ao responder a esses alertas, primeiro verifique com seu administrador M365 e Azure AD para verificar a atividade antes de levantar um evento de segurança.


Figura 13: Regras do Escritório 365 e Azure Helix


Figura 14: Descrição do alerta registrado pelo conector PTA

Caçando backdoors em registros de auditoria unificados M365 e logs AD do Azure

Se você suspeitar que uma conta de administrador global foi comprometida e deseja rever o Azure AD para indicadores de abuso potencial, o seguinte deve ser revisto (observe que esses mesmos conceitos podem ser usados para monitoramento proativo de log):

  • A partir de logs de logins de anúncios do Azure, monitore a atividade de logon das contas de serviço de sincronização do diretório on-premises. Esta conta é usada pelo serviço Azure AD Connect (Figura 15).


Figura 15: Azure AD Sign-ins

  • Na linha de base dos endereços IP usados por esta conta e certifique-se de que os IPs correspondam aos atribuídos à infraestrutura WAN no local. Se o invasor tiver configurado um Agente PTA em sua própria infraestrutura, ver um IP que não corresponde à sua linha de base pode ser um indicador de que um Agente PTA desonesto foi configurado pelo invasor (Figura 16).


Figura 16: Logins de login do Azure AD — conta on-premises Directory Synchronization Services

De Logins AD do Azure, monitor e aline Azure AD Sign-ins para o Conector proxy de aplicativo Azure AD. Certifique-se de validar nome de usuário, IP e localização.

Esses eventos são normalmente gerados apenas quando um novo agente PTA está conectado ao inquilino. Isso pode ser um indicador de que um invasor conectou um servidor PTA desonesto hospedado na infraestrutura de um invasor (Figura 17).


Figura 17: Logins de login do Azure AD — conector de proxy do aplicativo AD Azure

Se usar o Azure Sentinel, este evento também será registrado na tabela Azure AuditLogs como um “Register Connector” OperationName (Figura 18).


Figura 18: Registrar conector – Azure Sentinel logs

  • No Portal de Gerenciamento do Azure sob a lâmina Azure AD Connect, revise todos os servidores registrados executando o PTA Agent. O Agente de Autenticação e o IP devem corresponder à sua infraestrutura (Figura 19).
    • Faça login no https://portal.azure.com
      • Selecione Azure AD Connect > Autenticação de passagem


Figura 19: Status do agente de autenticação de aprovação do Azure Active Directory

  • Monitore e alerte para “Atividade de Administração de Diretórios” no registro de auditoria unificado do Office 365 Security & Compliance Center. Quando um invasor é capaz de criar uma federação de domínio dentro de um inquilino de nuvem comprometido e vinculá-lo à infraestrutura de propriedade do invasor, isso gerará atividade no log (Figura 21).
    • https://Protections.office.com/unifiedauitlog > Pesquisa de Log de Auditoria
    • Selecione Administração de diretórios ativa categoria para selecionar todas as atividades
    • Criar nova política de alerta (Figura 20)


Figura 20: Registro de Auditoria Unificada > Criar nova política de alerta


Figura 21: Registro de auditoria unificado filtrado para eventos relacionados ao domínio

  • Usando o Azure Sentinel, atividades de administração de diretórios mais granulares podem ser modificadas para atividades suspeitas. Isso inclui adições, exclusões e modificações de domínios e suas configurações de autenticação (Figura 22).
    • O monitoramento das operações de atividade do Office no Azure Sentinel pode permitir que uma organização valide se esta é uma atividade normalizada ou se um invasor está trabalhando na criação de um backdoor para PTA ou federação.
      • Tabela: OfficeActivity
        • Operação: Set-AcceptedDomain
        • Operação: Set-MsolDomainFederationSettings
        • Operação: Add-FederatedDomain
        • Operação: Domínio recém-aceito
        • Operação: Domínio de remoção aceito
        • Operação: Remove-FederatedDomain


Figura 22: Operações de OfficeActivity Azure Sentinel logs

Detecção no local

Se um invasor for capaz de comprometer a infraestrutura local e acessar um servidor executando serviços AD Connect ou ADFS com a intenção de aproveitar uma ferramenta como a AADInternals para expandir o escopo de seu acesso para incluir a detecção e contenção em tempo há que no local é fundamental. Os seguintes métodos podem ser aproveitados para garantir visibilidade e detecção otimizadas para o escopo das atividades descritas neste post:

  • Trate os servidores ADFS e Azure AD Connect como ativos de Nível 0.
    • Use um servidor dedicado para cada um. Não instale essas funções e servidor, além de outras. Muitas vezes estamos vendo o Azure AD Connect sendo executado em um servidor de arquivos.
  • Certifique-se de que o registro do PowerShell seja otimizado em servidores AD Connect e ADFS
  • Revise os registros operacionais do Microsoft-Windows-PowerShell/Operational nos registros do ADFS e do AADConnect Server.
    • Se o registro do PowerShell estiver ativado, procure o Event ID 4101. Este ID do evento gravará o evento onde a AADInternals foi instalada (Figura 23).


Figura 23: EventID 410 — Módulo instalado

  • Além disso, com este registro ativado, você poderá rever os comandos do PowerShell usados por um invasor.
    • No PowerShell, execute get-module -All e procure a presença de AADInternals (Figura 24).


Figura 24: Comando Get-Module para listar módulos instalados

  • Alerta para a presença de C:\PTASpy e C:\PTASpy\PTASpy.csv.
    • Este é o local padrão do arquivo de registro que contém registros de todas as contas que foram interceptadas pela ferramenta. Lembre-se, um invasor também pode usar isso para coletar credenciais, por isso é importante redefinir a senha dessas contas (Figura 25).


Figura 25: Atividade de registro PTASpy.csv

Atenuações

Para que esse ataque seja bem sucedido, um invasor deve obter privilégios administrativos em um servidor executando o Azure AD Connect e/ou obter direitos de administrador global dentro do M365. Práticas simples, como limitar e proteger adequadamente contas de administradores globais, bem como proteger adequadamente os ativos do Nível 0, podem reduzir consideravelmente o risco de um invasor usar com sucesso o PowerShell AADInternals contra sua organização.

  • Limite ou restrinja o acesso aos servidores Azure AD Connect.
    • Qualquer servidor que atue como provedor de identidade ou facilite a federação de identidade deve ser tratado como um ativo de Nível 0.
  • Crie contas de administrador globaldedicadas separadas .
    • Os administradores globais devem ser contas somente na nuvem.
    • Essas contas não devem reter qualquer licenciamento.
  • Implementar o MFA em todas as contas: administradores, usuários e serviços.
    • Se uma determinada conta não puder usar o MFA, aplique uma regra de acesso condicional que limite sua logon a uma rede confiável. Isso funciona particularmente bem para contas de serviço.
  • Estabeleça um roteiro para bloquear a autenticação do legado.
  • Limite quais contas são sincronizadas de locais para a nuvem.
    • Não sincronize contas privilegiadas ou de serviço na nuvem.
  • Use funções administrativasdo Azure.
    • Nem todo mundo ou tudo precisa ser um administrador global para administrar o meio ambiente.
  • Use a sincronização hash de senha sobre a autenticação de passagem.
    • Muitas organizações estão relutantes em sincronizar sua senha com o Azure AD. Os benefícios deste serviço superam muito os riscos. Ser capaz de usar listas de senhas proibidas globaise personalizadas , tanto para a nuvem quanto para o local,é um tremendo benefício.
  • Encaminhe todos os registros de auditoria unificados M365 e logs do Azure para um SIEM e construa detecções.
    • Certifique-se de que você está encaminhando os registros recomendados neste post e construindo as detecções e cartilhas apropriadas dentro de suas equipes de operações de segurança.
    • Monitore especificamente para:
      • Domínio aceito
      • Set-MsolDomainFederationSettings
      • Adicionar-FederadoDomínio
      • Domínio recém-aceito
      • Domínio aceito por remoção
      • Remove-FederatedDomain
  • Revise periodicamente todos os provedores de identidade e domínios personalizados configurados no inquilino M365.
    • Se um invasor tiver sucesso em obter privilégios administrativos globais, ele pode optar por adicionar seu próprio provedor de identidade e domínio personalizado para manter a persistência.

Agradecimentos

Quero agradecer especial a Daniel Taylor, Roberto Bamberger e Jennifer Kendall na Microsoft por colaborarem com Mandiant na criação deste post no blog.

FONTE: FIREEYE

Previous post O tamanho das SMBs não os torna imunes a ataques cibernéticos
Next post Dicas de segurança cibernética para o CIO doméstico de 2020

Deixe um comentário