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

Ótima pergunta.

Primeiras coisas primeiro - considero a maioria dos "testadores de penetração" como script kiddies. Meu preconceito pode não ser justo ou preciso, mas estou colocando este aviso de isenção de responsabilidade para que, se você detectar qualquer cinismo em meu tom, saiba de onde vem. Não estou dizendo que não existem pentesters habilidosos, mas esta é a minha generalidade.

(Equipe azul para sempre!)

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?

Você não forneceu informações suficientes para que alguém pudesse responder a esta pergunta completamente e com confiança. Você disse que seu aplicativo continha uma falha que permitia aos invasores enumerar contas de usuário. Estou tentando entender de que forma você acha que o AD precisa realizar o logging para sua aplicação.

Aparentemente, as falhas só apareciam no log de eventos local do servidor onde o aplicativo foi instalado.

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 dizem? Quem os registrou? Seu aplicativo? Ou janelas? Vá descobrir e talvez eu possa adicionar esclarecimentos adicionais à minha resposta.

Vou arriscar aqui com base em sua suposiçã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 estivessem 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 maneira diferente, dependendo se a conta do usuário existe ou não. Este não é um comportamento específico do Active Directory, mas também se aplica ao MIT Kerberos, Heimdal, etc. O KDC responderá comKDC_ERR_PREAUTH_REQUIREDse um nome de usuário válido foi apresentado sem dados de pré-autenticação, mesmo sem tentar uma autenticação real. Dessa forma, você pode enumerar nomes de usuário de um KDC. Mas como o invasor (ou a ferramenta que o invasor está usando, como KrbGuess - porque os pentesters estão no seu melhor quando estão usando as ferramentas de outras pessoas) não precisa continuar em uma tentativa de autenticação completa, nada é registrado porque nenhum autenticação real foi tentada!

Agora, para a sua próxima pergunta:

2) Se não, qual é a melhor maneira de monitorar e detectar ativamente esse tipo de ataque no futuro (espero sem ter que comprar muitos equipamentos novos).

Um par de coisas.

Primeiro, existem produtos pagos de nível empresarial projetados para detectar esses tipos de ataques (entre muitos outros). lá. 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 cada pacote que entra ou sai de seus controladores de domínio.

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

Outra coisa que pode te ajudar é a entrada do registro:

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

LogLevel = 1

Documentado aqui .

Se você habilitar essa entrada de registro, deverá ser inundado com eventos em 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 tal evento:

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 exatamente de onde vem o tsunami de solicitações do Kerberos. Isso nos leva de volta aos produtos corporativos de detecção de invasões que mencionei anteriormente.

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

Até agora, toda essa resposta foi baseada no protocolo Kerberos, que não posso nem mesmo dar como certo porque você deu tão poucos detalhes em sua postagem. No entanto, espero que isso ajude pelo menos um pouco.

Esta é uma pergunta interessante que eu adoraria ouvir uma resposta adequada. Encontrei algumas informações que Doug pode achar úteis, no entanto, sinto que podem ser um pouco inadequadas. Alguém provavelmente pode fornecer uma resposta expandida:

Faça login no servidor no qual deseja armazenar as informações de auditoria, Executar -> RSOP.MSC -> Configuração do computador -> Configurações do Windows -> Configurações de segurança -> Políticas locais -> Política de auditoria -> "Auditoria de eventos de logon de conta" & " Auditoria de eventos de logon"

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

Auditoria de eventos de logon de conta

Essa configuração de segurança determina se o sistema operacional audita cada vez que este computador valida as credenciais de uma conta.

Eventos de logon de conta são gerados sempre que um computador valida as credenciais de uma conta para a qual tem autoridade. Os membros do domínio e as máquinas não ingressadas no domínio têm autoridade para suas contas locais; controladores de domínio são todos autorizados para contas no domínio. A validação de credenciais pode dar suporte a um logon local ou, no caso de uma conta de domínio do Active Directory em um controlador de domínio, pode dar suporte a um logon em outro computador. A validação de credencial é sem estado, portanto, não há evento de logoff correspondente para eventos de logon de conta.

Se esta configuração de política for definida, o administrador poderá especificar se deve auditar apenas sucessos, apenas falhas, sucessos e falhas, ou não auditar esses eventos (ou seja, nem sucessos nem falhas).

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

Auditoria de eventos de logon

Essa configuração de segurança determina se o sistema operacional audita cada instância de um usuário que tenta fazer logon ou logoff nesse computador.

Os eventos de logoff são gerados sempre que a sessão de logon de uma conta de usuário conectada é encerrada. Se esta configuração de política for definida, o administrador poderá especificar se deve auditar apenas sucessos, apenas falhas, sucessos e falhas, ou não auditar esses eventos (ou seja, nem sucessos nem falhas).

Você precisaria basicamente habilitar essas políticas, definir as configurações de política e escolher "falha" se quiser apenas monitorar as tentativas com falha. Se você quiser, também pode monitorar os sucessos, mas pode tornar um pouco mais difícil analisar se você estiver apenas preocupado em procurar por esse tipo de ataque.

Se você está preocupado com configurações semelhantes às quais seus sistemas podem estar vulneráveis, recomendo examinar as configurações do STIG ( link ), quando usado em conjunto com um Scanner SCAP, pode realmente ajudar a destacar alguns dos riscos que sua organização pode estar voltado para. O visualizador do STIG tende a levantar alguns falsos positivos, mas se você ler os detalhes de cada problema, poderá achar que não é um bom começo.