CAPEv2
1.0.0
Uma caixa de areia é usada para executar arquivos maliciosos em um ambiente isolado enquanto instrumentam seu comportamento dinâmico e coletando artefatos forenses.
O CAPE foi derivado do cuco V1, que apresenta os seguintes recursos principais na plataforma Windows:
Cape complementa a saída de sandbox tradicional do Cuckoo com várias adições importantes:
Há uma instância gratuita online que qualquer um pode usar:
https://capesandbox.com - Para a ativação da conta, alcance para https://twitter.com/capesandbox
O Cuckoo Sandbox começou como um projeto do Google Summer of Code em 2010 no projeto HoneyNet. Foi originalmente projetado e desenvolvido por Claudio Guarnieri, o primeiro lançamento beta foi publicado em 2011. Em janeiro de 2014, foi lançado o Cuckoo V1.0.
2015 foi um ano crucial, com um garfo significativo na história de Cuckoo. O desenvolvimento do método de monitor e API de monitor original foi interrompido no projeto principal do cuco. Foi substituído por um monitor alternativo usando um formato de assinatura baseado em restructuredText , compilado via Linux Toolchain, criado por Jurriaan Bremer.
Na mesma época, um garfo chamado cuco-modificado foi criado pelo desenvolvimento continuado do Spengler 'Spender' do Brad, com melhorias significativas, incluindo suporte de 64 bits e a introdução de um compilador Visual Studio da Microsoft.
Durante o mesmo ano, o desenvolvimento de uma ferramenta dinâmica de extração de configuração e carga útil da linha de comando chamada Cape foi iniciada no contexto da segurança da informação por Kevin O'Reilly. O nome foi cunhado como um acrônimo de 'Extração de configuração e carga útil' e a pesquisa original focada no uso de ganchos de API fornecidos pela Biblioteca Detours da Microsoft para capturar cargas e configurações de malware descompactas. No entanto, tornou -se evidente que os ganchos da API por si só fornecem energia e precisão insuficientes para permitir a descompactação de cargas ou configurações de malware arbitrário.
Por esse motivo, a pesquisa começou em um novo conceito de depurador para permitir que o malware seja controlado e instrumentado com precisão, evitando o uso de interfaces de depuração da Microsoft, a fim de ser o mais furtivo possível. Esse depurador foi integrado à ferramenta de linha de comando baseada em desvios de prova de prova, combinando com ganchos de API e resultando em capacidades muito poderosas.
Quando o trabalho inicial mostrou que seria possível substituir os desvios da Microsoft pelo motor de conexão da API da Cuckoo-Modifiificado, nasceu a idéia para o Cape Sandbox. Com a adição do depurador, a descompacção automatizada, a classificação baseada em Yara e a extração de configuração integrada, em setembro de 2016 no 44Con, o Cape Sandbox foi lançado publicamente pela primeira vez: Cape versão 1.
No verão de 2018, o projeto teve a sorte de ver o início de enormes contribuições de Andriy 'Doomedraven' Brukhovetskyy, um colaborador de cuco de longa data. Em 2019, ele iniciou a gigantesca tarefa de portar Cape para Python 3 e em outubro daquele ano foi lançado Capev2.
O CAPE foi desenvolvido e melhorado continuamente para acompanhar os avanços nos recursos de malware e sistema operacional. Em 2021, foi adicionada a capacidade de programar o depurador de Cape durante a detonação por meio de verificações dinâmicas de YARA, permitindo que os desvios dinâmicos sejam criados para técnicas anti-Sandbox. O Windows 10 tornou-se o sistema operacional padrão e outras adições significativas incluem captura de carga útil interativa, AMSI (interface de varredura anti-Malware), 'Ghscall Hooking' com base nas contramedidas SYSCall baseadas em Microsoft Nirvana e no depurador.
O malware pode ser classificado em Cape através de três mecanismos:
A análise pode ser feita usando a própria estrutura de Cape, alternativamente, as seguintes estruturas são suportadas: RatDecoders, DC3-MWCP, Malduck ou Maco
def extract_config(data): que serão chamados por cape_utils.py e 0 complicações.
O CAPE aproveita muitas técnicas ou comportamentos de malware para permitir a captura de carga útil não embalada:
Esses comportamentos resultarão na captura de cargas úteis injetadas, extraídas ou descomprimidas para análises adicionais. Além disso, o CAPE cria automaticamente um despejo de processo para cada processo ou, no caso de uma DLL, a imagem do módulo da DLL na memória. Isso é útil para amostras embaladas com empacotadores simples, onde muitas vezes o despejo de imagem do módulo é totalmente descompactado.
Além dos mecanismos de descompacagem 'passiva' padrão do CAPE, é possível permitir a descompacagem 'ativa' que usa pontos de interrupção para detectar a escrita para regiões de memória recém -alocadas ou protegidas, a fim de capturar cargas úteis descompactadas o mais cedo possível antes da execução. Isso é ativado via caixa de compras de envio da web ou especificando a opção unpacker=2 e é deixado de fora por padrão, pois pode afetar a qualidade da detonação.
O CAPE pode ser programado via assinatura YARA para desfazer os embaladores específicos. Por exemplo, os empacotadores do tipo UPX são muito comuns e, embora na CAPE estes resultem em cargas úteis descompactadas sendo capturadas passivamente, a captura padrão é feita após o início da carga útil descompactada. Portanto, detectando os pacotes derivados da UPX dinamicamente via assinatura YARA personalizada e definindo um ponto de interrupção na instrução final do Packer, é possível capturar a carga útil em seu ponto de entrada original (OEP) antes de começar a executar.
A opção dump-on-api permite que um módulo seja despejado quando chama uma função de API específica que pode ser especificada na interface da Web (por exemplo dump-on-api=DnsQuery_A ).
O depurador permitiu que o Cabo continuasse evoluindo além de suas capacidades originais, que agora incluem desvios dinâmicos de anti-evasão. Como o malware moderno geralmente tenta fugir da análise nas caixas de areia, por exemplo, usando armadilhas de tempo para a virtualização ou a detecção de gancho de API, o CAPE permite que as contramedidas dinâmicas sejam desenvolvidas, combinando ações do depurador dentro de assinaturas de YARA para detectar malware evasivo à medida que ele detona e execute a manipulação de controle.
O acesso rápido ao depurador é possível com as opções de envio bp0 através bp3 , aceitando os valores de RVA ou VA para definir pontos de interrupção, e um pequeno rastreamento de instrução será produzido, governado pelas opções count e depth (por exemplo bp0=0x1234,depth=1,count=100 ). 
Para definir um ponto de interrupção no ponto de entrada do módulo, ep é usado em vez de um endereço (por exemplo, bp0=ep ). Alternativamente, break-on-return permite um ponto de interrupção no endereço de retorno de uma API enganchada (por exemplo break-on-return=NtGetContextThread ). Um parâmetro opcional base-on-api permite que a base de imagens para os pontos de interrupção RVA sejam definidos pela chamada da API (por exemplo base-on-api=NtReadFile,bp0=0x2345 ).
Opções action0 - action3 permite que as ações sejam executadas quando os pontos de interrupção são atingidos, como despejar regiões de memória (por exemplo, action0=dumpebx ) ou alterar o fluxo de controle de execução (por exemplo, action1=skip ). A documentação do CAPE contém outros exemplos de tais ações.
O repositório que contém o código para o monitor do CAPE é distinto.
Há um repositório comunitário de assinaturas contendo várias centenas de assinaturas desenvolvidas pela comunidade do CAPE. Todo o novo recurso da comunidade deve ser empurrado para esse repositório. Mais tarde, eles podem ser movidos para o núcleo se os desenvolvedores puderem e dispostos a mantê -los.
Contribua com este projeto, ajudando a criar novas assinaturas, analisadores ou contornos para outras famílias de malware. Atualmente, existem muitos em andamento, então assista a este espaço.
Um enorme agradecimento a @d00m3dr4v3n por portar capa sozinho para o Python 3.
Python3
Somente o rooter deve ser executado como root , o restante como usuário do CAPE . Correr como root vai mexer com as permissões.
conf !kvm-qemu.sh e cape2.sh devem ser executados na sessão tmux para evitar problemas do sistema operacional se as conexões ssh quebrarem.<username> por um padrão real.<WOOT> por dentro!sudo ./kvm-qemu.sh all <username> 2>&1 | tee kvm-qemu.logsudo ./cape2.sh base 2>&1 | tee cape.logconf .systemctl restart <service_name>journalctl -u <service_name>-h para o menu de ajuda. A execução do serviço no modo de depuração ( -d ) também pode ajudar.-h , mas verifique os scripts para entender o que estão fazendo.git pullpython3 utils/community.py -waf veja -h antes para garantir que você entenda git add --all
git commit -m '[STASH]'
git pull --rebase origin master
# fix conflict (rebase) if needed
git reset HEAD~1
# make sure kevoreilly repo has been added as a remote (only needs to be done once)
git remote add kevoreilly https://github.com/kevoreilly/CAPEv2.git
# make sure all your changes are commited on the branch which you will be merging
git commit -a -m '<your commit message goes here>'
# fetch changes from kevoreilly repo
git fetch kevoreilly
# merge kevoreilly master branch into your current branch
git merge kevoreilly/master
# fix merge conflicts if needed
# push to your repo if desired
git push
Se você usar o CAPEV2 em seu trabalho, cite -o conforme especificado no menu Github "citar este repositório".
pefile como cada versão dos pinos que desejam.pefile , como você já a instalou. Volia não há mais dor.
