Melhor maneira de rastrear a enumeração de nome de usuário de força bruta / tentativas de nome de usuário com falha AD

Question

Temos um Windows Server que tem um aplicativo que reside nele, que usa credenciais de domínio no login do aplicativo. Durante um recente teste de caneta, os testadores puderam usar o aplicativo para enumerar nomes de usuário de domínio válidos com base na resposta do aplicativo (ele forneceu uma resposta diferente para um nome de usuário inválido e uma senha inválida).

O aplicativo está sendo corrigido, por isso não revela essas informações, mas também acho que deveríamos ter detectado esse ataque, já que havia mais de 2000.000 tentativas de nome de usuário inválidas por um curto período de tempo. Nós não o vimos, mesmo quando nossos administradores estavam observando atentamente o Active Directory. Aparentemente, as falhas só apareceram no log de eventos local do servidor em que o aplicativo estava instalado.

Minha pergunta: 1) Existe uma maneira de fazer com que o Active Directory registre essas solicitações de nome de usuário com falha em um local central para que possamos notar um pico nelas?

2) Se não, qual é a melhor maneira de monitorar e detectar ativamente esse tipo de ataque no futuro (Espero que sem ter que comprar muito equipamento novo).

Obrigado pela sua ajuda.

    

Answer 1

Grande pergunta.

Primeiras coisas primeiro - eu considero a maioria dos "testadores de penetração" como sendo script kiddies. Meu viés pode não ser justo ou preciso, mas estou colocando este aviso de modo que, se você detectar algum cinismo em meu tom, saiba de onde ele está vindo. Eu não estou dizendo que há não pentesters habilidosos, mas essa é a minha geral generalidade.

(equipe azul para a vida!)

My question: 1) Is there a way to get Active Directory to log these failed username requests in a central location so we can notice a spike in them?

Você não forneceu informações suficientes para que alguém pudesse responder a essa pergunta com total segurança e com segurança. Você disse que o seu aplicativo foi encontrado para conter uma falha que permitia que os invasores enumerassem contas de usuários. Estou tentando entender de que maneira você acha que o AD precisa executar o registro para seu aplicativo

.

Apparently the failures only ever showed up in the local event log of the server where the application was installed.

Aparentemente as falhas apareceram no log de eventos no servidor? Ou as falhas apareceram no log de eventos no servidor? Se sim, o que exatamente os eventos disseram? Quem os registrou? Sua aplicação? Ou o Windows? Vá descobrir e eu poderei adicionar esclarecimentos adicionais à minha resposta.

Eu vou sair em um membro aqui baseado na sua presunção de que esses eventos deveriam ter sido registrados pelo Active Directory de alguma forma ... e se seus pentesters não estivessem realmente explorando uma falha em seu aplicativo, mas Em vez disso, estavam usando uma falha muito conhecida no próprio Kerberos para enumerar nomes de usuários? O próprio Kerberos contém o que eu consideraria uma falha de design na qual um invasor pode tentar milhares e milhares de tentativas de "pré-autenticação" (ou seja, um ataque de força bruta) e o KDC responderá de forma diferente dependendo se a conta do usuário existe ou não. Este não é um comportamento específico do Active Directory, mas se aplica igualmente ao MIT Kerberos, Heimdal, etc. O KDC responderá com KDC_ERR_PREAUTH_REQUIRED se um nome de usuário válido não tiver dados anteriores à autenticação, mesmo sem tentar uma autenticação real. Dessa maneira, você pode enumerar os nomes de usuário de um KDC. Mas como o invasor (ou a ferramenta que o atacante está usando, como o KrbGuess - porque os pentesters estão em seu melhor quando estão usando ferramentas de outras pessoas) não precisa continuar para uma tentativa de autenticação completa, nada é registrado porque não autenticação real foi tentada!

Agora, para sua próxima pergunta:

2) If not, what is the best way to monitor and actively detect this type of attack in the future (Hopefully without having to buy too much new equipment).

Algumas coisas.

Primeiro, existem produtos pagos de nível corporativo que são projetados para detectar esses tipos de ataques (entre muitas outras coisas.) Muitos fornecedores oferecem esses produtos, e as recomendações de produtos são fora do assunto para Serverfault, mas basta dizer que eles estão lá fora. Muitos desses produtos funcionam exigindo que você configure o espelhamento de porta entre seus controladores de domínio e esses "coletores de dados" para que eles vejam e analisem literalmente todo e qualquer pacote que entre ou saia de seus controladores de domínio.

(Desculpe, isso meio que "cai na sua cláusula" sem comprar coisas novas demais ".)

Outra coisa que pode ajudá-lo é a entrada do registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

LogLevel = 1

Documentado aqui .

Se você habilitar essa entrada do registro, deverá obter flooded com eventos no seu log de eventos de Segurança sobre erros do Kerberos que mencionam que a pré-autenticação do Kerberos é necessária. Um exemplo de um evento como esse:

A Kerberos Error Message was received:
 on logon session DOMAIN\serviceaccount
 Client Time: 
 Server Time: 12:44:21.0000 10/9/2012 Z
 Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
 Extended Error: 
 Client Realm: 
 Client Name: 
 Server Realm: DOMAIN
 Server Name: krbtgt/DOMAIN
 Target Name: krbtgt/DOMAIN@DOMAIN
 Error Text: 
 File: e
 Line: 9fe
 Error Data is in record data.

Mas isso pode ou não ajudá-lo se não especificar de onde exatamente vem o tsunami de solicitações do Kerberos. Isso nos leva de volta aos produtos corporativos de detecção de intrusão que mencionei anteriormente.

E não se esqueça do encaminhamento de eventos do Windows, que pode fazer com que seus servidores encaminhem os eventos para um local centralizado para serem analisados por qualquer ferramenta que você tenha à sua disposição.

Toda esta resposta até agora foi baseada no protocolo Kerberos, o qual eu nem posso dar por garantido porque você deu tão pouco detalhe no seu post. No entanto, espero que isso ajude pelo menos um pouco.

    

Answer 2

Esta é uma pergunta interessante que eu adoraria ouvir uma resposta adequada. Eu me deparei com algumas informações que Doug pode achar útil, no entanto, eu sinto que pode ser um pouco inadequado. Alguém pode provavelmente fornecer uma resposta expandida:

Faça login no servidor no qual você gostaria de ter as informações de auditoria armazenadas, Executar - > RSOP.MSC - > Configuração do Computador - > Configurações do Windows - > Configurações de segurança - > Políticas locais - > Política de Auditoria - > "Auditar eventos de logon da conta" & "Eventos de Logon de Auditoria"

A explicação para "eventos de logon da conta" é:

Audit account logon events

This security setting determines whether the OS audits each time this computer validates an account’s credentials.

Account logon events are generated whenever a computer validates the credentials of an account for which it is authoritative. Domain members and non-domain-joined machines are authoritative for their local accounts; domain controllers are all authoritative for accounts in the domain. Credential validation may be in support of a local logon, or, in the case of an Active Directory domain account on a domain controller, may be in support of a logon to another computer. Credential validation is stateless so there is no corresponding logoff event for account logon events.

If this policy setting is defined, the administrator can specify whether to audit only successes, only failures, both successes and failures, or to not audit these events at all (i.e. neither successes nor failures).

A explicação para "eventos de logon" diz:

Audit logon events

This security setting determines whether the OS audits each instance of a user attempting to log on to or to log off to this computer.

Log off events are generated whenever a logged on user account's logon session is terminated. If this policy setting is defined, the administrator can specify whether to audit only successes, only failures, both successes and failures, or to not audit these events at all (i.e. neither successes nor failures).

Você precisa essencialmente ativar essas políticas, definir as configurações de política e escolher "falha" se quiser apenas monitorar as tentativas com falha. Se você quiser, pode monitorar os sucessos também, mas pode dificultar a análise se você estiver preocupado em procurar por esse tipo de ataque.

Se você estiver preocupado com configurações semelhantes às quais seus sistemas podem estar vulneráveis, recomendo que você consulte as configurações do STIG ( link ), quando usado em conjunto com um SCAP Scanner, pode realmente ajudar a destacar alguns dos riscos que sua organização pode estar enfrentando. O visualizador STIG tende a levantar alguns falsos positivos, mas se você ler os detalhes do que cada edição possui, você pode achar que isso não é uma novidade.