Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir facilmente e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
Uma Lista de Controle de Acesso (ACL) consiste em um conjunto ordenado de Entradas de Controle de Acesso (ACEs) que ditam as proteções para um objeto e suas propriedades. Em essência, uma ACL define quais ações por quais princípios de segurança (usuários ou grupos) são permitidas ou negadas em um determinado objeto.
O processo de acesso a um arquivo envolve o sistema verificando o descritor de segurança do objeto em relação ao token de acesso do usuário para determinar se o acesso deve ser concedido e a extensão desse acesso, com base nos ACEs.
* **DACL:** Contém ACEs que concedem ou negam permissões de acesso a usuários e grupos para um objeto. É essencialmente a ACL principal que dita os direitos de acesso.
* **SACL:** Usado para auditar o acesso a objetos, onde ACEs definem os tipos de acesso a serem registrados no Log de Eventos de Segurança. Isso pode ser inestimável para detectar tentativas de acesso não autorizadas ou solucionar problemas de acesso.
Cada sessão de usuário está associada a um token de acesso que contém informações de segurança relevantes para essa sessão, incluindo identidades de usuário, grupo e privilégios. Esse token também inclui um SID de logon que identifica exclusivamente a sessão.
A Autoridade de Segurança Local (LSASS) processa solicitações de acesso a objetos examinando o DACL em busca de ACEs que correspondam ao principal de segurança que está tentando acessar. O acesso é imediatamente concedido se nenhum ACE relevante for encontrado. Caso contrário, o LSASS compara os ACEs com o SID do principal de segurança no token de acesso para determinar a elegibilidade de acesso.
* **ACE de Auditoria do Sistema**: Posicionado dentro de uma Lista de Controle de Acesso do Sistema (SACL), este ACE é responsável por gerar logs de auditoria nas tentativas de acesso a um objeto por usuários ou grupos. Ele documenta se o acesso foi permitido ou negado e a natureza do acesso.
4. Uma [**máscara de acesso**](https://docs.microsoft.com/en-us/openspecs/windows\_protocols/ms-dtyp/7a53f60e-e730-4dfe-bbe9-b21b62eb790b?redirectedfrom=MSDN), um valor de 32 bits especificando os direitos concedidos ao objeto.
A forma como as **ACEs** (regras que dizem quem pode ou não pode acessar algo) são colocadas em uma lista chamada **DACL** é muito importante. Isso ocorre porque uma vez que o sistema concede ou nega acesso com base nessas regras, ele para de procurar o restante.
Existe uma melhor maneira de organizar essas ACEs, chamada **"ordem canônica."** Este método ajuda a garantir que tudo funcione de forma suave e justa. Aqui está como funciona para sistemas como **Windows 2000** e **Windows Server 2003**:
* Nas regras específicas, coloque primeiro as que dizem **"não" (negar)** antes das que dizem **"sim" (permitir)**.
* Para as regras que vêm de outro lugar, comece com as mais próximas, como a pasta pai, e depois vá para trás. Novamente, coloque **"não"** antes de **"sim"**.
* Garante que se houver um **"não"** específico, ele seja respeitado, não importa quais outras regras de **"sim"** estejam lá.
* Permite que o proprietário de um item tenha a **última palavra** sobre quem entra, antes que quaisquer regras de pastas pai ou mais distantes entrem em jogo.
Fazendo as coisas dessa maneira, o proprietário de um arquivo ou pasta pode ser muito preciso sobre quem tem acesso, garantindo que as pessoas certas possam entrar e as erradas não.
Portanto, essa **"ordem canônica"** é tudo sobre garantir que as regras de acesso sejam claras e funcionem bem, colocando regras específicas primeiro e organizando tudo de maneira inteligente.
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir facilmente e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
Ao gerenciar o acesso a recursos, como uma pasta, usamos listas e regras conhecidas como Listas de Controle de Acesso (ACLs) e Entradas de Controle de Acesso (ACEs). Estas definem quem pode ou não pode acessar determinados dados.
Imagine que você tem uma pasta chamada Custos e deseja que todos a acessem, exceto a equipe de marketing. Ao configurar as regras corretamente, podemos garantir que a equipe de marketing seja explicitamente negada antes de permitir que todos os outros acessem. Isso é feito colocando a regra de negar acesso à equipe de marketing antes da regra que permite o acesso a todos.
Digamos que Bob, o diretor de marketing, precise acessar a pasta Custos, mesmo que a equipe de marketing geralmente não deva ter acesso. Podemos adicionar uma regra específica (ACE) para Bob que concede a ele acesso e colocá-la antes da regra que nega o acesso à equipe de marketing. Dessa forma, Bob obtém acesso apesar da restrição geral em sua equipe.
As ACEs são as regras individuais em um ACL. Elas identificam usuários ou grupos, especificam quais acessos são permitidos ou negados e determinam como essas regras se aplicam a subitens (herança). Existem dois tipos principais de ACEs:
* **ACEs Genéricas**: Estas se aplicam de forma ampla, afetando todos os tipos de objetos ou distinguindo apenas entre contêineres (como pastas) e não contêineres (como arquivos). Por exemplo, uma regra que permite aos usuários ver o conteúdo de uma pasta, mas não acessar os arquivos dentro dela.
* **ACEs Específicas do Objeto**: Estas fornecem um controle mais preciso, permitindo que regras sejam definidas para tipos específicos de objetos ou até mesmo propriedades individuais dentro de um objeto. Por exemplo, em um diretório de usuários, uma regra pode permitir que um usuário atualize seu número de telefone, mas não suas horas de login.
Cada ACE contém informações importantes como para quem a regra se aplica (usando um Identificador de Segurança ou SID), o que a regra permite ou nega (usando uma máscara de acesso) e como ela é herdada por outros objetos.
* As **ACEs Genéricas** são adequadas para cenários simples de controle de acesso, onde a mesma regra se aplica a todos os aspectos de um objeto ou a todos os objetos dentro de um contêiner.
* As **ACEs Específicas do Objeto** são usadas para cenários mais complexos, especialmente em ambientes como o Active Directory, onde pode ser necessário controlar o acesso a propriedades específicas de um objeto de forma diferente.
Em resumo, as ACLs e ACEs ajudam a definir controles de acesso precisos, garantindo que apenas as pessoas ou grupos certos tenham acesso a informações ou recursos sensíveis, com a capacidade de ajustar os direitos de acesso até o nível de propriedades individuais ou tipos de objetos.
| Tipo | Sinalizador que indica o tipo de ACE. O Windows 2000 e o Windows Server 2003 suportam seis tipos de ACE: Três tipos genéricos de ACE que são anexados a todos os objetos seguráveis. Três tipos de ACE específicos do objeto que podem ocorrer para objetos do Active Directory. |
| Flags | Conjunto de bits de controle de herança e auditoria. |
| Tamanho | Número de bytes de memória alocados para o ACE. |
| Máscara de Acesso | Valor de 32 bits cujos bits correspondem aos direitos de acesso para o objeto. Os bits podem ser ativados ou desativados, mas o significado da configuração depende do tipo de ACE. Por exemplo, se o bit que corresponde ao direito de ler permissões estiver ativado e o tipo de ACE for Negar, o ACE nega o direito de ler as permissões do objeto. Se o mesmo bit estiver ativado, mas o tipo de ACE for Permitir, o ACE concede o direito de ler as permissões do objeto. Mais detalhes da Máscara de Acesso aparecem na tabela seguinte. |
| SID | Identifica um usuário ou grupo cujo acesso é controlado ou monitorado por este ACE. |
