CAPEv2
1.0.0
Se utiliza un sandbox para ejecutar archivos maliciosos en un entorno aislado al tiempo que instrumenta su comportamiento dinámico y recolectando artefactos forenses.
CAPE se derivó de Cuckoo V1, que presenta las siguientes capacidades principales en la plataforma de Windows:
Cape complementa la salida de sandbox tradicional de Cuco con varias adiciones de claves:
Hay una instancia de demostración gratuita en línea que cualquiera puede usar:
https://capesandbox.com - para la activación de la cuenta Reach a https://twitter.com/capesandbox
Cuckoo Sandbox comenzó como un proyecto de Google Summer of Code en 2010 dentro del proyecto Honeynet. Fue diseñado originalmente y desarrollado por Claudio Guarnieri, el primer lanzamiento beta se publicó en 2011. En enero de 2014, se lanzó Cuco V1.0.
2015 fue un año crucial, con una bifurcación significativa en la historia de Cucoo. El desarrollo del método original del monitor y el enganche API se detuvo en el proyecto principal de cuco. Fue reemplazado por un monitor alternativo utilizando un formato de firma basado en restructuredText compilado a través de Linux Toolchain, creado por Jurriaan Bremer.
Casi al mismo tiempo, una bifurcación llamada cuco-modificado fue creada por Brad 'Spender' Spengler Desarrollo continuo del monitor original con mejoras significativas que incluyen soporte de 64 bits e introducir, lo que es más importante, introduciendo el compilador Visual Studio de Microsoft.
Durante ese mismo año, el desarrollo de una configuración dinámica de la línea de comandos y la herramienta de extracción de carga útil llamada CAPE fue iniciado en Context Information Security por Kevin O'Reilly. El nombre fue acuñado como un acrónimo de 'Extracción de configuración y carga útil' y la investigación original se centró en usar ganchos API proporcionados por la Biblioteca Detours de Microsoft para capturar cargas y configuración de malware desempaquetadas. Sin embargo, se hizo evidente que los ganchos de API solo proporcionan potencia y precisión insuficientes para permitir el desempaquetado de cargas útiles o configuraciones de malware arbitrario.
Por esta razón, la investigación comenzó en un nuevo concepto de depurador para permitir que el malware sea controlado e instrumentado con precisión mientras evita el uso de interfaces de depuración de Microsoft, para ser lo más sigiloso posible. Este depurador se integró en la herramienta de línea de comandos basada en desvíos de prueba de concepto, que se combina con ganchos de API y resultó en capacidades muy potentes.
Cuando el trabajo inicial mostró que sería posible reemplazar los desvíos de Microsoft con el motor API de Cuckoo-Modified, nació la idea de Cape Sandbox. Con la adición del depurador, el desempaquetado automático, la clasificación basada en Yara y la extracción integrada de configuración, en septiembre de 2016 en 44Con, Cape Sandbox se lanzó públicamente por primera vez: CAPE Versión 1.
En el verano de 2018, el proyecto tuvo la suerte de ver el comienzo de las grandes contribuciones de Andriy 'Doomedraven' Brukhovetskyy, un colaborador de cuco desde hace mucho tiempo. En 2019 comenzó la gigantesca tarea de portar a Cape a Python 3 y en octubre de ese año se lanzó Capev2.
CAPE se ha desarrollado y mejorado continuamente para mantener el ritmo de los avances en las capacidades de malware y del sistema operativo. En 2021, se agregó la capacidad de programar el depurador de Cape durante la detonación a través de escaneos dinámicos de Yara, lo que permite que se creen omitidos dinámicos para las técnicas anti-sandbox. Windows 10 se convirtió en el sistema operativo predeterminado, y otras adiciones significativas incluyen la captura de carga de la carga de escritorio interactiva, AMSI (interfaz de escaneo anti-malware), 'Syscall Counching' basado en Microsoft Nirvana y contramedidas directas/indirectas basadas en depuradores.
El malware se puede clasificar en CAPE a través de tres mecanismos:
El análisis se puede hacer utilizando el propio marco de Cape, alternativamente, se admiten los siguientes marcos: RatDecoders, DC3-MWCP, Malduck o Maco
def extract_config(data): que llamará cape_utils.py y 0 complicaciones.
CAPE aprovecha muchas técnicas o comportamientos de malware para permitir la captura de carga útil desempaquetada:
Estos comportamientos darán como resultado la captura de cargas útiles inyectadas, extraídas o descomprimidas para su posterior análisis. Además, Cape crea automáticamente un volcado de proceso para cada proceso o, en el caso de una DLL, la imagen del módulo de DLL en la memoria. Esto es útil para muestras repletas de empacadores simples, donde a menudo el volcado de imagen del módulo está completamente desempaquetado.
Además de los mecanismos predeterminados de desempaquetado 'pasivo' de Cape, es posible habilitar el desempaquetado 'activo' que utiliza puntos de interrupción para detectar la escritura en regiones de memoria recién asignadas o protegidas, para capturar cargas útiles desempaquetadas lo antes posible antes de la ejecución. Esto se habilita a través de la caja de envío web o especificando la opción unpacker=2 y se deja de manera predeterminada, ya que puede afectar la calidad de la detonación.
CAPE se puede programar a través de Yara Signature para desempaquetar empacadores específicos. Por ejemplo, los empacadores de tipo UPX son muy comunes y, aunque en Cape, estos resultan en la carga útil de la carga sin embalaje, la captura predeterminada se realiza después de que la carga útil desempaquetada ha comenzado a ejecutarse. Por lo tanto, al detectar los empacadores derivados de UPX dinámicamente a través de la firma Yara personalizada y establecer un punto de interrupción en la instrucción final del empacador, es posible capturar la carga útil en su punto de entrada original (OEP) antes de que haya comenzado a ejecutar.
La opción dump-on-api permite que se descarte un módulo cuando llama a una función API específica que se puede especificar en la interfaz web (por ejemplo, dump-on-api=DnsQuery_A ).
El depurador ha permitido que Cape continúe evolucionando más allá de sus capacidades originales, que ahora incluyen derivaciones dinámicas contra la evasión. Dado que el malware moderno comúnmente trata de evadir el análisis dentro de las cajas de arena, por ejemplo, utilizando trampas de tiempo para la virtualización o la detección de gancho API, CAPE permite que las contramedidas dinámicas se desarrollen combinando acciones de depuradores dentro de las firmas de Yara para detectar malware evasivo a medida que detiene, y realizar manipulación de flujo de control de control para que la muestra para detonar las acciones evasivas o evasivas.
El acceso rápido al depurador es posible con las opciones de envío bp0 a bp3 que aceptan los valores RVA o VA para establecer puntos de interrupción, con lo cual se emitirá una breve traza de instrucciones, gobernada por opciones count y depth (por ejemplo bp0=0x1234,depth=1,count=100 ). 
Para establecer un punto de interrupción en el punto de entrada del módulo, se usa ep en lugar de una dirección (por ejemplo, bp0=ep ). Alternativamente, break-on-return permite un punto de interrupción en la dirección de retorno de una API enganchada (por ejemplo, break-on-return=NtGetContextThread ). Un parámetro opcional base-on-api permite que la base de imagen para los puntos de interrupción de RVA se establezca mediante una llamada API (por ejemplo base-on-api=NtReadFile,bp0=0x2345 ).
Opciones action0 - action3 Permitir que las acciones se realicen cuando se alcanzan los puntos de interrupción, como las regiones de memoria de descarga (por ejemplo, action0=dumpebx ) o cambiar el flujo de control de ejecución (por ejemplo, action1=skip ). La documentación del Cabo contiene más ejemplos de tales acciones.
El repositorio que contiene el código para el monitor del Cabo es distinto.
Hay un depósito comunitario de firmas que contienen varios cientos de firmas desarrolladas por la comunidad del Cabo. Todas las nuevas características de la comunidad deben ser empujadas a ese repositorio. Más tarde se pueden trasladar a Core si los desarrolladores son capaces y están dispuestos a mantenerlos.
Contribuya a este proyecto ayudando a crear nuevas firmas, analizadores o derivaciones para más familias de malware. Actualmente hay muchos en las obras, así que mira este espacio.
Un gran agradecimiento a @D00M3DR4V3N por Porting Cape por sí solo a Python 3.
Python3
Solo Rooter debe ejecutarse como root , el resto como usuario de Cape . Ejecutar como root se meterá con los permisos.
conf !kvm-qemu.sh y cape2.sh deben ejecutarse a partir de la sesión tmux para evitar problemas del sistema operativo si las conexiones ssh se rompen.<username> con un patrón real.<WOOT> adentro!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 el menú de ayuda. Ejecutar el servicio en modo de depuración ( -d ) también puede ayudar.-h , pero consulte los scripts para comprender lo que están haciendo.git pullpython3 utils/community.py -waf Ver -h antes para asegurarse de que comprenda 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
Si usa CAPEV2 en su trabajo, cíquelo como se especifica en el menú GitHub "cita este repositorio".
pefile como la versión de alfileres que desean.pefile , ya que ya lo tiene instalado. Volia no más dolor.
