Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e automatizar facilmente fluxos de trabalho com as ferramentas comunitárias mais avançadas do mundo.\
* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Uma **ACL é uma lista ordenada de ACEs** que define as proteções que se aplicam a um objeto e suas propriedades. Cada **ACE** identifica um **princípio de segurança** e especifica um **conjunto de direitos de acesso** que são permitidos, negados ou auditados para esse princípio de segurança.
Quando um usuário tenta acessar um arquivo, o sistema Windows executa um AccessCheck 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 dos ACEs definidos.
Um DACL (frequentemente mencionado como ACL) identifica os usuários e grupos aos quais são atribuídas ou negadas permissões de acesso a um objeto. Ele contém uma lista de ACEs emparelhados (Conta + Direito de Acesso) para o objeto seguro.
SACLs permitem monitorar o acesso a objetos seguros. ACEs em um SACL determinam **quais tipos de acesso são registrados no Log de Eventos de Segurança**. Com ferramentas de monitoramento, isso pode gerar um alarme para as pessoas certas se usuários maliciosos tentarem acessar o objeto seguro, e em um cenário de incidente, podemos usar os logs para rastrear os passos de volta 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 logon. O sistema cria um token de acesso quando o usuário faz o login. **Cada processo executado** em nome do usuário **possui 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 logon (Identificador de Segurança) que identifica a sessão de logon atual.
Quando uma thread tenta acessar um objeto seguro, o LSASS (Autoridade de Segurança Local) concede ou nega o acesso. Para fazer isso, o **LSASS pesquisa o DACL** (Lista de Controle de Acesso Discricionário) no fluxo de dados SDS, procurando ACEs que se apliquem à thread.
**Cada ACE no DACL do objeto** especifica os direitos de acesso que são permitidos ou negados para um princípio de segurança ou sessão de logon. Se o proprietário do objeto não tiver criado nenhum ACE no DACL para esse objeto, o sistema concede acesso imediatamente.
| **`ACE de acesso negado`** | Usado dentro de um DACL para mostrar que um usuário ou grupo está explicitamente negado o acesso a um objeto |
| **`ACE de acesso permitido`** | Usado dentro de um DACL para mostrar que um usuário ou grupo está explicitamente concedido o acesso a um objeto |
| **`ACE de auditoria do sistema`** | Usado dentro de um SACL para gerar logs de auditoria quando um usuário ou grupo tenta acessar um objeto. Ele registra se o acesso foi concedido ou não e que tipo de acesso ocorreu |
Cada ACE é composto pelos seguintes `quatro` componentes:
1. O identificador de segurança (SID) do usuário/grupo que tem acesso ao objeto (ou nome do principal graficamente)
2. Uma flag que denota o tipo de ACE (ACE de acesso negado, permitido ou de auditoria do sistema)
3. Um conjunto de flags que especificam se os contêineres/objetos filhos podem herdar a entrada ACE do objeto primário ou pai
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 ocorra um dos seguintes eventos:
* **Um ACE de acesso negado nega explicitamente** qualquer um dos direitos de acesso solicitados a um dos beneficiários listados no token de acesso da thread.
* **Um ou mais ACEs de acesso permitido** para beneficiários listados no token de acesso da thread concedem explicitamente todos os direitos de acesso solicitados.
* Todos os ACEs foram verificados e ainda há pelo menos **um direito de acesso solicitado** que **não foi explicitamente permitido**, nesse caso, o acesso é implicitamente **negado**.
### Ordem dos ACEs
Porque o **sistema para de verificar os ACEs quando o acesso solicitado é explicitamente concedido ou negado**, a ordem dos ACEs em um DACL é importante.
A ordem preferida dos ACEs em um DACL é chamada de "ordem canônica". Para o Windows 2000 e o Windows Server 2003, a ordem canônica é a seguinte:
1. Todos os ACEs **explícitos** são colocados em um grupo **antes** de qualquer ACE **herdado**.
2. Dentro do grupo de ACEs **explícitos**, os ACEs de **negar acesso** são colocados **antes dos ACEs de permitir acesso**.
3. Dentro do grupo **herdado**, os ACEs herdados do **objeto filho vêm primeiro**, e **então** os ACEs herdados do **avô**, **e assim por diante** na árvore de objetos. Depois disso, os ACEs de **negar acesso** são colocados **antes dos ACEs de permitir acesso**.
A figura a seguir mostra a ordem canônica dos ACEs:
* Um ACE de **negar acesso explícito é aplicado independentemente de qualquer ACE de permitir acesso explícito**. Isso significa que o proprietário do objeto pode definir permissões que permitem acesso a um grupo de usuários e negam acesso a um subconjunto desse grupo.
* Todos os **ACEs explícitos são processados antes de qualquer ACE herdado**. 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) para criar e **automatizar fluxos de trabalho** com facilidade, usando as ferramentas comunitárias mais avançadas do mundo.\
Você deseja negar ao grupo de Marketing acesso a uma pasta de Custos. Se os ACEs da pasta de Custos estiverem em ordem canônica, o ACE que nega o acesso ao Marketing vem antes do ACE que permite a Todos.
Durante uma verificação de acesso, o sistema operacional percorre os ACEs na ordem em que eles aparecem no DACL do objeto, para que o ACE de negação seja processado antes do ACE de permissão. Como resultado, os usuários que são membros do grupo de Marketing são negados o acesso. Todos os outros têm acesso ao objeto.
Neste exemplo, a pasta de Custos tem um ACE herdável que nega o acesso ao Marketing (objeto pai). Em outras palavras, todos os usuários que são membros (ou filhos) do grupo de Marketing são negados o acesso por herança.
Você deseja permitir o acesso a Bob, que é o diretor de Marketing. Como membro do grupo de Marketing, Bob é negado o acesso à pasta de Custos por herança. O proprietário do objeto filho (usuário Bob) define um ACE explícito que permite o acesso à pasta de Custos. Se os ACEs do objeto filho estiverem em ordem canônica, o ACE explícito que permite o acesso de Bob vem antes de qualquer ACE herdado, incluindo o ACE herdado que nega o acesso ao grupo de Marketing.
Durante uma verificação de acesso, o sistema operacional alcança o ACE que permite o acesso de Bob antes de chegar ao ACE que nega o acesso ao grupo de Marketing. Como resultado, Bob tem acesso ao objeto, mesmo sendo membro do grupo de Marketing. Outros membros do grupo de Marketing são negados o 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:
Os ACEs são fundamentalmente semelhantes. O que os diferencia é o grau de controle que eles oferecem sobre a herança e o acesso ao objeto. Existem dois tipos de ACE:
Um ACE genérico oferece controle limitado sobre os tipos de objetos filhos que podem herdar deles. Essencialmente, eles só podem distinguir entre contêineres e não contêineres.
Por exemplo, o DACL (Lista de Controle de Acesso Discricionário) em um objeto de Pasta no NTFS pode incluir um ACE genérico que permite que um grupo de usuários liste 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, o ACE que permite a operação pode ser marcado como um ACE de CONTAINER\_INHERIT\_ACE. Apenas objetos Contêiner na pasta (ou seja, outras pastas) herdam o ACE. Objetos não contêineres (ou seja, arquivos) não herdam o ACE do objeto pai.
Um ACE genérico se aplica a um objeto inteiro. Se um ACE genérico dá a um determinado usuário 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 maioria das informações em um objeto de arquivo é armazenada como dados do objeto; portanto, há pouca necessidade de controles separados nas propriedades de um arquivo.
Por exemplo, a ACL de um objeto de OU (Unidade Organizacional) pode ter um ACE específico do objeto que é marcado para herança apenas por objetos de Usuário. Outros tipos de objetos, como objetos de Computador, não herdarão o ACE.
Essa capacidade é o motivo pelo qual os ACEs específicos do objeto são chamados de específicos do objeto. Sua herança pode ser limitada a tipos específicos de objetos filhos.
Um ACE específico do objeto pode ser aplicado 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 os ACEs específicos do objeto tornam isso possível.
Por exemplo, ao definir permissões para um objeto de Usuário, você pode usar um ACE específico do objeto para permitir que o Principal Self (ou seja, o usuário) tenha acesso de Gravação à propriedade Phone-Home-Primary (homePhone), e você pode usar outros ACEs específicos do objeto para negar o acesso do Principal Self à propriedade Logon-Hours (logonHours) e outras propriedades que definem restrições na conta do usuário.
| 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. |
| 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 a seguir. |
| SID | Identifica um usuário ou grupo cujo acesso é controlado ou monitorado por este ACE. |
* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** com facilidade, usando as ferramentas comunitárias mais avançadas do mundo.\
