O usuário analyst já possui um shell no lab-linux, e o CORP.LOCAL\svcuser já realiza login no LAB-WIN01. Nenhum desses pontos de acesso inicial representa um acesso administrativo. A questão da avaliação é se um erro de configuração local permite que qualquer uma das contas ultrapasse o limite de privilégios local para root ou SYSTEM, e se é possível comprovar esse risco sem executar um exploit. Um comando permitido no sudoers, um caminho de serviço com permissão de escrita ou uma credencial armazenada podem constituir evidência suficiente quando a conta, a configuração e os pré-requisitos estão alinhados.
Todas as atividades deste curso ocorrem dentro dos laboratórios offline fixos (Ubuntu 22.04 e Windows Server 2022) que possuímos ou para os quais temos autorização explícita de avaliação. O método gera descobertas passíveis de comprovação, e não payloads, cadeias de exploração ou etapas de evasão. No Ubuntu, uma solicitação sudo e seu resultado podem deixar evidências de autorização em /var/log/auth.log e no diário do sistema (journal), enquanto atividades de privilégio no Windows devem estar vinculadas ao log de Segurança relevante ou a evidências do serviço.
O laboratório fixo torna visíveis o limite de privilégios e os locais onde as evidências são armazenadas:
Este diagrama mostra por que a enumeração começa no host. A configuração relevante e a evidência de seu uso geralmente estão em lados opostos da mesma fronteira de privilégios; portanto, uma constatação requer ambos, e não apenas uma configuração suspeita isolada.
Como uma fronteira visível não estabelece um caminho que a atravesse, cada etapa de enumeração produz quatro resultados interconectados. Uma lista de hipóteses é um conjunto classificado de possíveis classes de vetores, como comandos Linux delegados, tarefas agendadas, configuração fraca de serviços do Windows ou credenciais expostas a uma conta não administrativa. Uma hipótese não é uma constatação. Ela só se torna uma quando a configuração do host satisfaz os pré-requisitos do vetor.
Por exemplo, o fato de um analyst (analista) ver um executável com permissão elevada não prova a elevação. É preciso determinar quem é o proprietário do arquivo, se o analyst pode influenciá-lo, qual componente privilegiado o executa e se o contexto de execução realmente atinge o root. O equivalente no Windows não é apenas notar a existência de um serviço. Precisamos da conta de serviço, do caminho do binário, do controle de acesso e das permissões detidas por CORP.LOCAL\svcuser.
As mesmas evidências respondem a uma pergunta de um defensor. No Ubuntu, atividades do sudo (aceitas ou rejeitadas) podem identificar a conta que fez a chamada, o usuário de destino, o diretório de trabalho e o comando; arquivos de política como /etc/sudoers e /etc/sudoers.d/ explicam por que a ação foi permitida. Um defensor pode comparar esses registros com a regra de delegação pretendida e emitir alertas sobre comandos privilegiados incomuns ou alterações inesperadas nos arquivos de política.
Os resultados da avaliação distinguem uma rota plausível de uma condição de escalonamento de privilégios passível de relato: