O que vem depois que uma conta de domínio do Windows foi comprometida?

Estamos nos preparando para um cenário em que uma das contas de um domínio fica comprometida - o que fazer a seguir?

Desabilitar a conta seria a minha primeira resposta a seguir, mas tivemos protestos aqui há algumas semanas e eles foram capazes de usar logins com hash de um usuário administrador que saiu alguns meses atrás.

Nossas duas respostas até agora são:

Excluir a conta e recriá-la (cria novo SID, mas também mais drama para o usuário e trabalha para nós)
Altere a senha pelo menos três vezes e desative a conta

Qual seria o seu método ou o que você recomendaria?

active-directory security

— JurajB
fonte

Se uma conta de administrador foi comprometida, crie mais contas de administrador para seu próprio objetivo. Se for uma conta privada baixa (usuário normal), faça varreduras de rede e encontre uma conta de administrador para se comprometer. Possuir um usuário comum coloca seu pé na porta para realizar mais ataques "direcionados".

— precisa

Você está dizendo que a conta do usuário administrador que saiu há alguns meses atrás não foi desativada na partida dessa pessoa? Acho que não vejo como esse exemplo fala da eficácia ou ineficácia de contas desativadas. Qual é a lógica para alterar a senha três vezes e não uma vez?

— Todd Wilcox

@ToddWilcox, a conta foi desativada logo quando a pessoa saiu e os grupos foram removidos (essa é uma prática padrão quando as pessoas saem), no entanto, eles alegaram ter conseguido acessar usando-a.

— JurajB

Portanto, não foi removido corretamente - você quer fichas para ser expirado e acesso para essa conta removido em todos os sistemas

— Rory Alsop

Respostas:

Se apenas uma conta de usuário padrão for comprometida, alterar a senha uma vez e deixar a conta ativada deve ser bom. Um hash não funcionará depois que a senha for alterada. Também não funcionará se a conta estiver desativada. Como testador de caneta, eu me pergunto se os testadores de caneta estavam usando tíquetes Kerberos. Sob certas circunstâncias, isso pode continuar funcionando se uma senha for alterada ou se uma conta for desabilitada OU mesmo excluída (consulte os links para a atenuação).

Se uma conta de administrador de domínio foi comprometida, está literalmente terminada. Você precisa colocar seu domínio offline e alterar TODAS as senhas. Além disso, a senha da conta krbtgt precisaria ser alterada duas vezes, caso contrário, os invasores ainda poderão emitir tíquetes Kerberos válidos com as informações roubadas. Depois de fazer tudo isso, você poderá colocar seu domínio novamente online.

Implemente uma política de bloqueio de conta, para que as senhas alteradas não possam ser adivinhadas. Não renomeie suas contas. Os invasores podem descobrir facilmente os nomes de login.

Outro ponto importante é treinar seus usuários. Eles provavelmente fizeram algo imprudente que significava que a conta foi comprometida. O invasor pode nem saber a senha; eles podem estar apenas executando processos como essa conta. Por exemplo, se você abrir um anexo de malware que forneça ao invasor acesso à sua máquina, eles estarão sendo executados como sua conta. Eles não sabem sua senha. Eles não podem obter o hash da sua senha, a menos que você seja um administrador. Não permita que os usuários executem como administradores locais em suas estações de trabalho. Não permita que administradores de domínio façam login em estações de trabalho com direitos de administrador de domínio - nunca!

Links para mais informações / mitigações:

https://blogs.microsoft.com/microsoftsecure/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/

http://www.infosecisland.com/blogview/23758-A-Windows-Authentication-Flaw-Allows-DeletedDisabled-Accounts-to-Access-Corporate-Data.html

https://mva.microsoft.com/en-us/training-courses/how-to-avoid-golden-ticket-attacks-12134

— bao7uo
fonte

E se você trabalha em um ambiente relativamente permissivo, como a academia? Você pode estar lidando com usuários que possuem posse e não desejam ser "treinados" e, como eles têm posse, você não tem permissão para se livrar deles ou reduzir seus privilégios.

— Katherine Villyard

Eu sempre recomendo as melhores práticas. Sempre haverá alguns tipos de organizações que não podem implementá-lo 100%. Algumas pessoas se consideram acima da lei e algumas organizações vêem a posse / egos como mais importante do que aplicar políticas e segurança de maneira justa e uniforme. Essas pessoas e organizações terão que assumir a responsabilidade pelas consequências de suas ações. Vamos torcer para que essas organizações acadêmicas não estão procurando depois de uma pesquisa importante, que seria de valor aos interesses estrangeiros .....

— bao7uo

Eu fiz alguns cursos de MVA sobre o bilhete de ouro e a mitigação da pena, mas meu entendimento era que ele lembra duas senhas; portanto, é necessário alterá-lo pelo menos duas vezes, não apenas uma. Até o script para o krbtgt faz isso duas vezes.

— JurajB

não é possível editar o que foi dito acima, adicionando: Até o script do krbtgt faz isso duas vezes. Então, a melhor opção (para conta de usuário) não seria alterar a senha duas vezes e depois desabilitar a conta?

— JurajB

You need to bring your domain offline. Isso pode funcionar para um pequeno escritório, mas é improvável que uma grande empresa possa colocar seu domínio / floresta offline.

— Greg Askew

eles foram capazes de usar logins com hash de um usuário administrador que saiu alguns meses atrás.

Os hashes de credenciais roubados não funcionam para contas desabilitadas, a menos que estejam em um computador que não esteja conectado à rede. O processo ainda precisa solicitar um ticket ou autenticar com um controlador de domínio. Não é possível fazer isso se a conta estiver desativada.

Você precisa desativar as contas administrativas dos ex-funcionários quando eles saem.

— Greg Askew
fonte

Como os hashes de credenciais roubados ajudam o invasor? Se eles não tiverem a senha real, não há como recuperar a senha do hash (exceto para obter senhas pequenas usando tabelas arco-íris), correto? Não tenho certeza do que estou perdendo aqui.

— Chirag Bhatia - chirag64

@ ChiragBhatia-chirag64 Você está assumindo que os esquemas de autenticação são resistentes à reprodução. Eles podem não ser, nesse caso, os hashes são tudo o que você precisa para autenticar.

— Jonas Schäfer

Você pode dar um exemplo em que o esquema de autenticação do Windows usa o hash real em vez da senha de texto? Desculpe se isso soa como uma pergunta estúpida, eu nunca vi tal implementação antes (ou talvez eu entenda mal mecanismo de autenticação Windows)

— Chirag Bhatia - chirag64

@ ChiragBhatia-chirag64 en.m.wikipedia.org/wiki/Pass_the_hash

— Greg Askew

@GregAskew obrigado, eu não fazia ideia de que isso era algo na autenticação do Windows. Surpreendentemente, eles não usam algo como SSL para enviar a senha. Parece-me um enorme problema de segurança.

— precisa saber é o seguinte

Supondo uma conta de usuário padrão, convém considerar:

Mude a senha.
Desabilite a conta.
Renomeie a conta (nome de usuário suspeito) e crie uma nova conta para o usuário afetado.
Adicione a conta suspeita a um grupo de segurança "Usuários desabilitados / comprometidos".

Para o número 4, já existe uma diretiva de grupo que faz o seguinte:

Negar acesso a este computador da rede: "Usuários desabilitados / comprometidos"
Negar logon pelos Serviços de Área de Trabalho Remota: "Usuários desabilitados / comprometidos"
Negar logon localmente: "Usuários desabilitados / comprometidos"

Para uma conta de administrador de domínio, toda a sua rede é brindada.

— Katherine Villyard
fonte

por que você sugere alterar a senha mais de uma vez?

— precisa

se uma conta de administrador de domínio foi comprometida, isso significa que todas as contas de usuário estão comprometidas. você gostaria que eles renomeassem todas as contas de usuário?

— bao7uo

@PHPaul: Dependendo da incursão, se uma conta ainda estiver em uso, renomear pode ser uma tática válida. E é claro que eles não recomendam renomear todas as contas.

— Greg Askew