Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
<summary><strong>Aprenda hacking no 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ê quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo do** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios do github** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Uma **ACL é uma lista ordenada de ACEs** que define as proteções aplicadas a um objeto e suas propriedades. Cada **ACE** identifica um **principal de segurança** e especifica um **conjunto de direitos de acesso** que são permitidos, negados ou auditados para esse principal de segurança.
Quando um usuário tenta acessar um arquivo, o sistema Windows executa uma verificação de acesso e compara o descritor de segurança com o token de acesso do usuário e avalia se o usuário tem acesso concedido e que tipo de acesso dependendo das ACEs definidas.
Uma DACL (frequentemente mencionada como ACL) identifica os usuários e grupos que têm permissões de acesso atribuídas ou negadas a um objeto. Ela contém uma lista de ACEs emparelhadas (Conta + Direito de Acesso) para o objeto protegível.
SACLs possibilitam o monitoramento do acesso a objetos protegidos. ACEs em uma SACL determinam **quais tipos de acesso são registrados no Log de Eventos de Segurança**. Com ferramentas de monitoramento, isso pode acionar um alarme para as pessoas certas se usuários maliciosos tentarem acessar o objeto protegido, e em um cenário de incidente, podemos usar os logs para rastrear os passos no tempo. E por último, você pode habilitar o registro para solucionar problemas de acesso.
Cada **usuário logado** no sistema **possui um token de acesso com informações de segurança** para aquela sessão de login. O sistema cria um token de acesso quando o usuário faz login. **Cada processo executado** em nome do usuário **tem uma cópia do token de acesso**. O token identifica o usuário, os grupos do usuário e os privilégios do usuário. Um token também contém um SID de login (Identificador de Segurança) que identifica a sessão de login atual.
Quando uma thread tenta acessar um objeto protegível, o LSASS (Autoridade de Segurança Local) concede ou nega acesso. Para fazer isso, o **LSASS pesquisa a DACL** (Lista de Controle de Acesso Discricionário) no fluxo de dados SDS, procurando por ACEs que se aplicam à thread.
**Cada ACE na DACL do objeto** especifica os direitos de acesso que são permitidos ou negados para um principal de segurança ou sessão de login. Se o proprietário do objeto não criou nenhuma ACE na DACL para aquele objeto, o sistema concede acesso imediatamente.
| **`ACE de acesso negado`** | Usada dentro de uma DACL para mostrar que um usuário ou grupo tem acesso explicitamente negado a um objeto |
| **`ACE de acesso permitido`** | Usada dentro de uma DACL para mostrar que um usuário ou grupo tem acesso explicitamente concedido a um objeto |
| **`ACE de auditoria do sistema`** | Usada dentro de uma SACL para gerar logs de auditoria quando um usuário ou grupo tenta acessar um objeto. Ela registra se o acesso foi concedido ou não e que tipo de acesso ocorreu |
4. Uma [máscara de acesso](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/7a53f60e-e730-4dfe-bbe9-b21b62eb790b?redirectedfrom=MSDN) que é um valor de 32 bits que define os direitos concedidos a um objeto
O sistema examina cada ACE em sequência até que um dos seguintes eventos ocorra:
* **Uma ACE de acesso negado explicitamente nega** qualquer um dos direitos de acesso solicitados a um dos beneficiários listados no token de acesso da thread.
* **Uma ou mais ACEs de acesso permitido** para beneficiários listados no token de acesso da thread concedem explicitamente todos os direitos de acesso solicitados.
* Todas as ACEs foram verificadas e ainda há pelo menos **um direito de acesso solicitado** que **não foi explicitamente permitido**, nesse caso, o acesso é implicitamente **negado**.
Como o **sistema para de verificar as ACEs quando o acesso solicitado é explicitamente concedido ou negado**, a ordem das ACEs em uma DACL é importante.
1. Todas as ACEs **explícitas** são colocadas em um grupo **antes** de quaisquer ACEs **herdadas**.
2. Dentro do grupo de ACEs **explícitas**, ACEs de **acesso negado** são colocadas **antes das ACEs de acesso permitido**.
3. Dentro do grupo **herdado**, ACEs que são herdadas do **pai do objeto filho vêm primeiro**, e **depois** ACEs herdadas do **avô**, **e assim** por diante na árvore de objetos. Depois disso, ACEs de **acesso negado** são colocadas **antes das ACEs de acesso permitido**.
* Uma ACE de **acesso negado explícito é aplicada independentemente de qualquer ACE de acesso permitido explícito**. Isso significa que o proprietário do objeto pode definir permissões que permitem acesso a um grupo de usuários e negar acesso a um subconjunto desse grupo.
* Todas as **ACEs explícitas são processadas antes de qualquer ACE herdada**. Isso é consistente com o conceito de controle de acesso discricionário: o acesso a um objeto filho (por exemplo, um arquivo) está a critério do proprietário do filho, não do proprietário do objeto pai (por exemplo, uma pasta). O proprietário de um objeto filho pode definir permissões diretamente no filho. O resultado é que os efeitos das permissões herdadas são modificados.
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Você quer negar ao grupo de Marketing o acesso a uma pasta de Custos. Se as ACEs da pasta de Custos estiverem em ordem canônica, a ACE que nega o acesso ao Marketing vem antes da ACE que permite a Todos.
Durante uma verificação de acesso, o sistema operacional percorre as ACEs na ordem em que aparecem na DACL do objeto, de modo que a ACE de negação é processada antes da ACE de permissão. Como resultado, usuários que são membros do grupo de Marketing são negados acesso. Todos os outros têm acesso permitido ao objeto.
Neste exemplo, a pasta de Custos tem uma ACE herdável que nega acesso ao Marketing (o objeto pai). Em outras palavras, todos os usuários que são membros (ou filhos) do grupo de Marketing são negados acesso por herança.
Você quer permitir acesso a Bob, que é o diretor de Marketing. Como membro do grupo de Marketing, Bob é negado acesso à pasta de Custos por herança. O proprietário do objeto filho (usuário Bob) define uma ACE explícita que permite acesso à pasta de Custos. Se as ACEs do objeto filho estiverem em ordem canônica, a ACE explícita que permite o acesso de Bob vem antes de qualquer ACE herdada, incluindo a ACE herdada que nega acesso ao grupo de Marketing.
Durante uma verificação de acesso, o sistema operacional alcança a ACE que permite o acesso de Bob antes de chegar à ACE que nega acesso ao grupo de Marketing. Como resultado, Bob tem acesso permitido ao objeto, mesmo sendo membro do grupo de Marketing. Outros membros do grupo de Marketing são negados acesso.
Como mencionado anteriormente, uma ACL (Lista de Controle de Acesso) é uma lista ordenada de ACEs (Entradas de Controle de Acesso). Cada ACE contém o seguinte:
ACEs são fundamentalmente semelhantes. O que as diferencia é o grau de controle que oferecem sobre a herança e o acesso ao objeto. Existem dois tipos de ACE:
Uma ACE genérica oferece controle limitado sobre os tipos de objetos filhos que podem herdá-la. Essencialmente, elas só podem distinguir entre contêineres e não contêineres.
Por exemplo, a DACL (Lista de Controle de Acesso Discricionário) em um objeto Pasta no NTFS pode incluir uma ACE genérica que permite a um grupo de usuários listar o conteúdo da pasta. Como listar o conteúdo de uma pasta é uma operação que só pode ser realizada em um objeto Contêiner, a ACE que permite a operação pode ser marcada como CONTAINER_INHERIT_ACE. Apenas objetos Contêiner na pasta (ou seja, outros objetos Pasta) herdam a ACE. Objetos não contêineres (ou seja, objetos Arquivo) não herdam a ACE do objeto pai.
Uma ACE genérica se aplica a um objeto inteiro. Se uma ACE genérica concede a um usuário específico acesso de Leitura, o usuário pode ler todas as informações associadas ao objeto — tanto dados quanto propriedades. Isso não é uma limitação séria para a maioria dos tipos de objetos. Objetos de Arquivo, por exemplo, têm poucas propriedades, que são todas usadas para descrever características do objeto em vez de armazenar informações. A maior parte das informações em um objeto de Arquivo é armazenada como dados do objeto; portanto, há pouca necessidade de controles separados sobre as propriedades de um arquivo.
Por exemplo, a ACL de um objeto OU (Unidade Organizacional) pode ter uma ACE específica de objeto marcada para herança apenas por objetos Usuário. Outros tipos de objetos, como objetos Computador, não herdarão a ACE.
Essa capacidade é a razão pela qual ACEs específicas de objeto são chamadas de específicas de objeto. Sua herança pode ser limitada a tipos específicos de objetos filhos.
Uma ACE específica de objeto pode se aplicar a qualquer propriedade individual de um objeto ou a um conjunto de propriedades desse objeto. Esse tipo de ACE é usado apenas em uma ACL para objetos do Active Directory, que, ao contrário de outros tipos de objetos, armazenam a maior parte de suas informações em propriedades. Muitas vezes é desejável colocar controles independentes em cada propriedade de um objeto do Active Directory, e ACEs específicas de objeto tornam isso possível.
Por exemplo, ao definir permissões para um objeto Usuário, você pode usar uma ACE específica de objeto para permitir que o Principal Self (ou seja, o usuário) tenha acesso de Escrita à propriedade Phone-Home-Primary (homePhone), e você pode usar outras ACEs específicas de objeto para negar ao Principal Self acesso à propriedade Logon-Hours (logonHours) e outras propriedades que estabelecem restrições na conta do usuário.
| Tipo | Flag que indica o tipo de ACE. O Windows 2000 e o Windows Server 2003 suportam seis tipos de ACE: Três tipos de ACE genéricas que são anexadas a todos os objetos protegíveis. Três tipos de ACE específicas de objeto que podem ocorrer para objetos do Active Directory. |
| Tamanho | Número de bytes de memória que são alocados para a ACE. |
| Máscara de acesso | Valor de 32 bits cujos bits correspondem a direitos de acesso para o objeto. Os bits podem ser definidos como ligados ou desligados, mas o significado da configuração depende do tipo de ACE. Por exemplo, se o bit que corresponde ao direito de ler permissões
