withsecurelabs/esfangESF ferramenta modular de ingestão para desenvolvimento e pesquisa.
Esta é uma ferramenta concebida para o consumo modular de eventos do EndpointSecurity Framework (ESF) no ambiente macOS. Esta é a minha tentativa de superar uma série de problemas encontrados com ferramentas existentes, incluindo coisas como descarte silencioso de dados, consumo estrito de tipos de eventos, falta de suporte para tipos alternativos de eventos de dados e sobrecarga do manipulador de acesso a arquivos.
Esta ferramenta depende fortemente do excelente trabalho realizado por Chris Ross, Omark-Ikram e a equipe da Objective-See com suas ferramentas ProcessMonitor, Appmon e EndpointSecurityDemo. Minha compreensão central e aplicabilidade da ingestão de dados do ESF foram enormemente aprimoradas e impulsionadas ao examinar seus trabalhos, que fizeram grande parte do trabalho pesado para tornar este desenvolvimento possível. Esta ferramenta tentou extrapolar os melhores elementos dessas ferramentas e expandi-los para permitir uma ação de consumo do ESF caso a caso, com base nas necessidades do investigador.
As ferramentas existentes, incluindo ferramentas mais refinadas como o Crescendo da FireEye, sofrem de uma série de problemas associados ao próprio ESF que, em testes, parecem estar relacionados à forma como o cliente ESF ingere os dados do subsistema. O principal problema encontrado foi a perda silenciosa de dados. Em testes, quando numerosos tipos de eventos eram ingeridos, os resultados, quando comparados à ingestão de um único tipo de evento, mostravam disparidade nos dados acumulados. Em testes, eventos críticos relacionados a atividades maliciosas não estavam no conjunto de dados adquirido que estava presente na ingestão de um único tipo de evento.
O propósito principal desta ferramenta era triplo:
Para este fim, a ferramenta permite ao usuário especificar quais tipos de eventos deseja coletar durante as operações, dentre os 51 tipos de eventos NOTIFY disponíveis (os tipos de eventos AUTH foram omitidos nesta ferramenta). Isso significa que pesquisadores podem direcionar tipos específicos de eventos relacionados a operações específicas que desejam monitorar, além de ajudar a reduzir a perda silenciosa de dados associada, diminuindo a quantidade total de tipos de eventos coletados pelo cliente.
A saída de dados é distribuída em arquivos de log individuais por tipo de evento, que por sua vez são agrupados em arquivos de gênero de eventos, como processo, arquivo, sockets, etc. Todos os logs são escritos em JSON para fácil ingestão e podem ser expandidos pelos usuários alterando o código-fonte para coletar campos adicionais descritos na documentação de tipos de eventos fornecida pela Apple.
NOTAS FUTURAS -
Para prevenir a perda silenciosa de dados, uma solução potencial seria usar multithreading na ferramenta para permitir que múltiplos clientes ESF rodem simultaneamente, com cada um coletando um subconjunto dos tipos de eventos. Isso poderia potencialmente superar o limite interno que é atingido e causa a perda de dados observada. Simplesmente não tive tempo de implementar os controles adicionais para isso.
COMO USAR
Requer que o SIP esteja desabilitado!
Infelizmente, como este é um código POC de desenvolvimento, você não poderá usá-lo com o SIP habilitado, pois o acesso ao subsistema ESF é restrito a binários assinados. Como este não é assinado, o SIP deve ser desabilitado para uso. Portanto, use apenas em máquinas que não sejam de produção.
Existem três tipos de execução: você pode especificar o ID de um event_id do arquivo de configuração, especificar um group_id do arquivo de configuração, ou referenciar o arquivo de configuração com as linhas dos IDs de tipos de eventos ou grupos descomentadas.
Exemplo 1 = Coletar apenas eventos ES_EVENT_TYPE_NOTIFY_EXEC: ./ESFang -id 2
Exemplo 2 = Coletar eventos do gênero File: ./ESFang -group 2
Exemplo 3 = Coletar tipos de eventos ou grupos especificados pelo arquivo de configuração: ./ESFang -config ./ESF_config.txt
NOTA SOBRE O FILTRO CODIFICADO
Dentro do código-fonte há um filtro de processo codificado que se encontra nas linhas 460 - 469. Este filtro pode ser manipulado para capturar um PID, PPID ou nome de processo específico. Isso foi adicionado como uma solução "improvisada" para fins de filtragem específica. Tentativas de tornar isso dinâmico na linha de comando para alimentar o Inspector falharam. Portanto, foi deixado codificado.
NOTA SOBRE O MUTER DE PROCESSO CODIFICADO
Dentro do código-fonte há uma capacidade de muting de processo codificada encontrada nas linhas 471 - 491. Este filtro pode ser usado para silenciar a captura de eventos específicos com base no caminho do processo ou do processo pai, respectivamente. Isso deve ser usado com cautela, pois todos os processos que corresponderem ao nome especificado serão silenciados se o processo ou o pai de qualquer atividade corresponder. Isso estava em teste beta quando foi lançado.
