jymcheong/autottpTáticas, Técnicas e Procedimentos Automatizados
Táticas, Técnicas e Procedimentos Automatizados. Reexecutar sequências complexas manualmente para testes de regressão, avaliações de produto, gerar dados para pesquisadores etc. pode ser tedioso. Brinquei com a ideia de facilitar a criação de scripts para o Empire (ou qualquer framework/produto/kit de ferramentas que forneça APIs como Metasploit (RPC), Cobalt-Strike etc.) usando uma IDE como o Visual Studio Code (ou equivalente). Então comecei a projetar o AutoTTP. Isso ainda está em andamento. Testado com Empire 2.2.
YouTube - Visão Geral e Aprofundamento em Técnicas Selecionadas
No meu caso, as táticas são organizadas de acordo com meu modelo de Ciclo de Vida de Ataque. Existem outros modelos como Kill-Chain(R) da Lockheed Martin, Ciclo de Vida de Ataque da Mandiant e ATT&CK da Mitre. Qualquer que seja o modelo, uma "Tática" essencialmente agrupa técnicas, por exemplo, execução de código/execução de payload pode ser alcançada de várias maneiras:
Eu uso "Estágio" para agrupar "Táticas" relevantes. Se você olhar a árvore de origem, a estrutura de pastas reflete a coluna de Táticas da matriz. A matriz também menciona controles respectivos para cada tática ofensiva. Como esses estágios surgiram?
O diagrama de Venn no meio do ciclo vermelho é do "Three Tenets for Secure Cyber-Physical System Design and Assessment" do Dartmouth College. Ele define as condições necessárias e suficientes, ou simplesmente os requisitos de qualquer ataque físico/lógico bem-sucedido. Adicionei o anel vermelho (estágios) ao redor do diagrama de Venn para ilustrar fluxos ofensivos típicos que, em última análise, levam ao impacto na Confidencialidade das Informações, Integridade e Disponibilidade ou Segurança do Sistema, se relacionado a Ciber-Físico (pense em Infraestrutura Crítica de Informação).
Um atacante pode começar no Estágio 1 e ir direto para o Estágio 4, por exemplo, credenciais de administrador padrão em uma página de administração exposta publicamente. Não precisa ser linear (estágio 1->2->3->4). Após a infiltração inicial, ele(a) pode ter realizado alguma coleta de informações internas (reconhecimento) primeiro antes de elevar privilégios na primeira máquina e então lançar um comando remoto para outra máquina alvo na mesma rede. Para a próxima máquina vítima, é um Estágio 2; entrega e execução bem-sucedida de payload que permite ao atacante ganhar comando e controle sobre mais uma máquina.
O arquivo à esquerda é um script de procedimento, o da direita é um script de técnica. Observe que o script de procedimento não está repleto de muitos detalhes específicos do Empire; muitos detalhes estão encapsulados no script de técnica. O script de procedimento deve focar na sequência de técnicas usando informações dos ativos, por exemplo, hostname/ip, para qual e-mail enviar o payload, qual técnica de payload etc.
O exemplo de "o usuário é administrador?" na verdade consiste em algumas etapas, já que há pelo menos 3 possibilidades conforme descrito nos comentários do script. Podemos, é claro, criar "macros" personalizadas no Empire, Metasploit e outros, mas isso se torna fortemente integrado a uma estrutura/produto específico. Queremos aproveitar as ferramentas disponíveis e organizar técnicas reutilizáveis em módulos para combinar e combinar em um nível Processual (ou seja, a automação).
Aproveitei os módulos bem estruturados do Empire para criar uma classe Python de autocompletar. Em vez de digitar o nome completo do módulo (ex. powershell/situational_awareness....), basta usar os recursos de autocompletar da IDE.
Para cada módulo, existem opções (na maioria, senão em todos os frameworks). O problema com o Empire é que, quando você o executa como rest/headless (abordarei isso mais tarde), NÃO há console para ver as opções do módulo. Na classe auxiliar de autocompletar, cada módulo tem uma subclasse options. As opções obrigatórias são prefixadas conforme mostrado acima, para que possamos preencher essas opções com valores antes de chamar um módulo.
A descrição de cada módulo também está incluída como parte da documentação da classe Python e será exibida ao passar o mouse sobre a classe. Como existem 276 módulos (a partir do Empire 2.1), essa classe auxiliar precisará de algum script para ser criada! Fonte: https://gist.github.com/jymcheong/22c2eede978c8eb694945e3347c20c6b
Com IDEs como Visual Studio Code (ou equivalente), pode-se aproveitar a observação de variáveis de depuração, percorrer o script ou até modificar o script durante a depuração/execução passo a passo após conhecer a estrutura dos valores de retorno. A documentação das APIs REST está lá para o Empire, mas às vezes não sabemos exatamente os valores de retorno até executarmos o módulo. Por esse motivo, isso leva ao próximo tópico.
Por mais que queiramos fazer tudo na IDE, você precisará do console. O autor do DeathStar, já sabia disso ao desenvolver aquele script que automatiza a conquista de Administrador de Domínio usando Empire. Peguei emprestada a ideia dele, mas adaptei sua abordagem de threading para o Empire 2.1, já que sua abordagem não funciona para a função refatorada de iniciar a API RESTful. Fonte: https://gist.github.com/jymcheong/6a7668ecf73c29dd1d234d1c76ef438c
NÃO há necessidade de hackear o script do Empire, pois o Empire 2.2 possui o manipulador de loop de comando ao executar o modo REST. No entanto, NÃO interaja com o agente enquanto usa a API para obter o resultado do agente.
Agradecimentos a @radioboyQ pelo EmpireAPIWrapper, @allfro e @Mikaayenson pelo pymetasploit, e a @byt3bl33d3r, MTFBWU.
