Josimar Hedler
Índice
Mesmo com a crescente adoção de soluções em nuvem, o Active Directory continua sendo o principal pilar de identidade em muitas organizações. Ele concentra usuários, grupos, permissões, serviços e relações de confiança que, quando comprometidas, permitem a um atacante se mover lateralmente, escalar privilégios e assumir o controle completo do ambiente. Por esse motivo, o AD permanece como um dos alvos mais explorados em ataques modernos, tanto externos quanto internos.
Tradicionalmente, a segurança do Active Directory é tratada de forma reativa, baseada em controles de prevenção como senhas fortes, políticas de bloqueio, antivírus e, em alguns casos, ferramentas de EDR. No entanto, esses mecanismos nem sempre são suficientes para identificar comportamentos suspeitos em estágios iniciais do ataque, especialmente quando o invasor já possui algum nível de acesso legítimo ao ambiente. É nesse cenário que entram as Honey Accounts, uma abordagem de segurança baseada em deception (engano controlado).
Honey Accounts são contas deliberadamente criadas para não serem utilizadas por usuários reais, mas que possuem características atrativas para atacantes, como nomes sugestivos, descrições estratégicas ou associações cuidadosamente planejadas. Qualquer tentativa de autenticação, enumeração ou uso dessas contas deve ser tratada como um forte indicativo de atividade maliciosa, permitindo que a equipe de segurança detecte ameaças antes que elas causem impacto real ao negócio.
Neste artigo, vamos explorar de forma prática como planejar, criar e monitorar Honey Accounts em um ambiente de Active Directory local, utilizando recursos nativos da plataforma. O objetivo não é apenas criar contas falsas, mas implementar um mecanismo simples, eficaz e de baixo custo para fortalecer a detecção de ataques direcionados à identidade, elevando o nível de maturidade de segurança do ambiente on-premises.
Atenção: As implementações apresentadas em nossos artigos foram desenvolvidas com base em documentações oficiais e nas boas práticas recomendadas pela Microsoft. Entretanto, enfatizamos que qualquer implementação deve ser previamente testada em ambientes de homologação ou testes para garantir a segurança e a estabilidade do ambiente de produção
Criando contas Honey Account no Active Directory
O propósito das contas honey account é que elas se comportem, aos olhos de um possível atacante, como identidades legítimas associadas a serviços sensíveis ou operações importantes do ambiente. Essas contas não devem entregar sinais óbvios de que se tratam de armadilhas, pois isso reduziria sua eficácia como mecanismo de detecção. Por outro lado, torná-las excessivamente realistas pode gerar riscos, caso sejam configuradas com privilégios ou acessos desnecessários. O ponto crítico está justamente em alcançar o equilíbrio adequado criar uma identidade suficientemente plausível para despertar interesse malicioso, mas cuidadosamente controlada para não oferecer qualquer possibilidade de uso indevido ou impacto à segurança da organização.
Finalmente Hands-On
- Vá para o Server Manager
- Clique em Active Directory Users and Computers
Seleciona a UO que deseja criar seu user
Informe um nome completo plausível e defina um nome de usuário compatível com o padrão do ambiente. Em seguida, selecione Next.
Defina uma senha forte e exclusiva para a conta, garantindo que ela não seja reutilizada nem registrada em qualquer outro local, para preservar a segurança e o realismo da conta, marque as seguintes opções:
– O usuário não pode alterar a senha
– A senha nunca expira
Em seguida, clique em Next, revise as informações do usuário Honey e finalize selecionando Finish
Atribuindo associação de grupos e de login para contas honey account
Com a conta de usuário honey criada, o passo mais crítico em termos de segurança é assegurar que ela não ofereça qualquer valor a um invasor, mesmo que a senha venha a ser comprometida.
Os grupos representam o pilar do controle de acesso no Active Directory. Dessa forma, vincular o usuário honey a grupos aparentemente valiosos ajuda a atrair e desviar a atenção de possíveis atacantes.
No meu cenário, optei por criar grupos com nomes chamativos, no entanto, é fundamental avaliar quais denominações fariam sentido no seu ambiente, despertando interesse sem gerar riscos à segurança.
Restringindo Horários de Login e Acesso
Para evitar qualquer tentativa de autenticação nessas contas de segurança, é possível restringir o horário de login.
- Selecione seu usuário Honey
- Depois clique em Account
- Logon Hours
- Na próxima janela defina os horário de trabalho da sua organização para ser realista, e depois em OK
Definir horários de logon para uma conta honey é uma decisão que deve ser avaliada com cuidado. É perfeitamente possível optar por não definir nenhum horário, especialmente em ambientes onde esse controle não é utilizado para usuários comuns.
No entanto, é importante lembrar que, apesar de ser uma conta honey account, ela ainda é uma conta válida do domínio. Ao definir um horário de logon, criamos contexto para detecção. Se alguém tentar utilizar essa conta fora do horário permitido ou em dias não úteis, esse comportamento se torna um forte indicativo de atividade anômala.
Nesse cenário, o horário deixa de ser apenas um mecanismo de bloqueio e passa a atuar como telemetria de segurança, enriquecendo a análise de eventos e investigações.
Por outro lado, a aplicação desse tipo de controle pode levantar questionamentos. Um possível atacante pode se perguntar: “por que essa conta possui restrição de horário enquanto outras não?”. Por isso, é fundamental analisar como esse controle se encaixa na realidade de cada ambiente, garantindo que a conta honey permaneça coerente, realista e alinhada aos padrões da organização.
Restringindo acesso
- Selecione seu usuário honey
- Depois cliquem e Account
- Log On To / Logon Workstations
- Selecione The following computers
- Adicione o computar name, vale lembra para que siga mesma nomenclatura já utilizada em seu ambiente
Essa alternativa ainda mais realista é vincular a conta honey a uma máquina real de testes ou laboratório da equipe de TI. Dessa forma, a restrição de logon permanece funcional, o host existe no ambiente e o controle deixa de levantar questionamentos sobre inconsistência, ao mesmo tempo em que limita o impacto de um possível uso indevido
Ativando auditoria em contas do Active Directory Honey
Após a implantação da conta honey, a prioridade passa a ser a detecção. Qualquer tipo de interação com essa conta deve ser tratada com tolerância zero seja uma tentativa de login malsucedida ou até mesmo a leitura de um atributo pois isso indica a presença de um invasor ativo no ambiente.
Vamos configurar auditoria de logon via GPO
É possível utilizar a Configuração Avançada de Políticas de Auditoria para registrar de forma precisa os eventos relevantes nos Controladores de Domínio.
Abra o Group Policy Management, seleciona a UO aonde esta seu usuário honey, e cliquem com botão direto do mouse, e selecione Create a GPO in this domain, and link it here, deu um nome sugestivo, depois clique com botão direto na politica que acabou de criar e selecione Edit
- Clique em Policies
- Depois em Windows Settings
- Cliquem em Security Settings
- Expanda Local policies, e clique em Audit Policy
- Clique dua vezes em Audit account logon event, mas todas as opções e depois clique em OK, repita mesmo processo em Audit logon events, depois em OK
Habilitar a auditoria em nível de objeto para fins de reconhecimento
Execute este procedimento para identificar atividades maliciosas ainda na fase inicial de reconhecimento, mesmo uma simples tentativa de consultar informações da conta honey será registrada como um evento de segurança.
No Active Directory Users and Computers, acesse View -> Advanced Features
Selecione seu usuário honey, clique com botão direto do mouse, e em Properties
Depois selecione a aba Security, e em seguida clique em Advanced
Depois na próxima tela, selecione Aditing, Depois em Add
Escolha do Principal na auditoria de contas honey
Ao configurar auditoria em objetos do Active Directory, a escolha do principal impacta diretamente a qualidade dos eventos gerados, embora opções como Everyone, Authenticated Users e Domain Users possam parecer semelhantes à primeira vista, cada uma possui comportamentos distintos e efeitos práticos diferentes.
Everyone inclui praticamente todas as identidades que interagem com o domínio, como usuários, computadores, serviços e processos internos, apesar de funcional, essa opção tende a gerar um volume elevado de eventos legítimos, dificultando a identificação de atividades realmente suspeitas, por esse motivo, seu uso em contas honey não é recomendado em ambientes reais.
Authenticated Users abrange todas as identidades autenticadas no domínio, incluindo usuários, computadores e contas de serviço, essa opção oferece um equilíbrio maior, reduzindo o ruído em comparação com Everyone, mas ainda capturando interações relevantes que envolvem autenticação válida, pode ser útil em ambientes com muitas automações ou serviços que acessam o diretório.
Domain Users limita a auditoria exclusivamente a usuários reais do domínio, essa abordagem reduz significativamente o volume de eventos e aumenta a precisão da detecção, sendo especialmente eficaz para contas honey cujo objetivo é identificar enumeração manual, tentativas de abuso e comportamentos típicos de um atacante interativo.
Em cenários de honey, a escolha do principal deve priorizar clareza e valor analítico, e não apenas volume de logs, por isso, Domain Users ou Authenticated Users tendem a ser opções mais adequadas, dependendo do perfil do ambiente e do nível de automação existente.
Para esse artigo selecionei Domain Users
- Select o Principal
- Em Type quero monitorar Fail and Succes, por isso selecione All, mas se preferir logs apenas de uma opção você pode escolher.
- Em Applies to, selecione This object only
- Em Permisions, selecione Red all properties, Write all properties, Read permissions e Reset password
As permissões auditadas na conta honey foram selecionadas com foco em detectar comportamentos relevantes e reduzir ruído, a leitura de propriedades permite identificar enumeração e reconhecimento do ambiente, enquanto a escrita de propriedades e a leitura de permissões indicam tentativas de modificação ou análise avançada do objeto, a auditoria de reset de senha foi incluída por representar um forte indicativo de tentativa de sequestro da conta.
Analisando o Visualizador de Eventos para identificar tentativas de logon malsucedidas envolvendo usuários Honey Account
No Log de Segurança, é possível consultar diretamente as tentativas de autenticação tanto bem-sucedidas quanto malsucedidas associadas à conta de usuário honey, por meio dos eventos de ID 4624 e 4625.
PowerShell
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[
EventData[Data[@Name='TargetUserName']='<HoneyAccount>']
and
System[(EventID='4624')]
or
System[(EventID='4625')]
]
</Select>
</Query>
</QueryList> Abra o Event Viewer em um controlador de domínio e acesse Logs do Windows -> Security.
No painel Actions, selecione Filter Current log… e alterne para a guia XML.
Marque a opção Edit query manually e confirme clicando em Yes na mensagem exibida.
Em seguida, cole a consulta XML abaixo, substituindo <HoneyAccount> pelo nome da conta de usuário honey, e finalize clicando em OK.
Conclusão
A configuração de contas honey account no Active Directory vai além da criação de um usuário “isca”. Quando bem planejadas, essas contas se tornam sensores valiosos para detecção de atividades suspeitas. Controles como horários de logon, restrição por estação de trabalho e auditoria de objetos devem ser aplicados com foco em realismo e contexto, evitando ruído excessivo. Mais do que bloquear ações, o objetivo é observar comportamentos que não deveriam acontecer. Em segurança, entender o que monitorar é tão importante quanto como monitorar.
Link de referência: Audit Directory Service Changes
Link de referência: Configure Windows event auditing
Link de referência: Best practices for securing Active Directory