kevoreilly/capev2Extracción de Configuración y Carga Útil de Malware
Un sandbox se utiliza para ejecutar archivos maliciosos en un entorno aislado mientras se instrumenta su comportamiento dinámico y se recopilan artefactos forenses.
CAPE se derivó de Cuckoo v1, que cuenta con las siguientes capacidades principales en la plataforma Windows:
CAPE complementa la salida tradicional del sandbox de Cuckoo con varias adiciones clave:
Hay una instancia de demostración gratuita en línea que cualquiera puede usar:
https://capesandbox.com - Para la activación de la cuenta, contacte a https://twitter.com/capesandbox
Cuckoo Sandbox comenzó como un proyecto de Google Summer of Code en 2010 dentro de The Honeynet Project. Fue diseñado y desarrollado originalmente por Claudio Guarnieri, la primera versión beta se publicó en 2011. En enero de 2014, se lanzó Cuckoo v1.0.
2015 fue un año crucial, con una bifurcación significativa en la historia de Cuckoo.
El desarrollo del monitor original y el método de hooking de API se detuvo en el
proyecto principal de Cuckoo. Fue reemplazado por un monitor alternativo
utilizando un formato de firma basado en restructuredText compilado mediante la cadena de herramientas de Linux,
creado por Jurriaan Bremer.
Casi al mismo tiempo, una bifurcación llamada Cuckoo-modified fue creada por Brad 'Spender' Spengler, continuando el desarrollo del monitor original con mejoras significativas, incluido el soporte de 64 bits y, lo que es importante, la introducción del compilador Microsoft Visual Studio.
Durante ese mismo año, comenzó el desarrollo de una herramienta dinámica de línea de comandos para la extracción de configuración y carga útil llamada CAPE en Context Information Security por Kevin O'Reilly. El nombre se acuñó como acrónimo de 'Config And Payload Extraction' (Extracción de Configuración y Carga Útil) y la investigación original se centró en el uso de hooks de API proporcionados por la biblioteca Detours de Microsoft para capturar cargas útiles de malware desempaquetadas y configuración. Sin embargo, se hizo evidente que los hooks de API por sí solos no proporcionan suficiente potencia y precisión para permitir el desempaquetado de cargas útiles o configuraciones de malware arbitrario.
Por esta razón, comenzó la investigación sobre un concepto novedoso de depurador para permitir que el malware sea controlado e instrumentado con precisión, evitando 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 Detours como prueba de concepto, combinándose con hooks de API y dando como resultado capacidades muy potentes.
Cuando el trabajo inicial mostró que sería posible reemplazar Microsoft Detours con el motor de hooking de 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 fue lanzado públicamente por primera vez: CAPE versión 1.
En el verano de 2018, el proyecto tuvo la suerte de ver el comienzo de enormes contribuciones de Andriy 'doomedraven' Brukhovetskyy, un colaborador de larga data de Cuckoo. En 2019 comenzó la titánica tarea de portar CAPE a Python 3 y en octubre de ese año se lanzó CAPEv2.
CAPE se ha desarrollado y mejorado continuamente para mantenerse al día con los avances tanto en malware como en las capacidades del sistema operativo. En 2021, se añadió la capacidad de programar el depurador de CAPE durante la detonación mediante escaneos YARA dinámicos, lo que permitió la creación de bypass dinámicos para técnicas anti-sandbox. Windows 10 se convirtió en el sistema operativo predeterminado, y otras adiciones significativas incluyen escritorio interactivo, captura de carga útil de AMSI (Interfaz de Escaneo Anti-Malware), 'hooking de syscall' basado en Microsoft Nirvana y contramedidas de syscall directas/indirectas basadas en depurador.
El malware se puede clasificar en CAPE mediante tres mecanismos:
El análisis se puede realizar utilizando el propio framework de CAPE; alternativamente, se admiten los siguientes frameworks: RATDecoders, DC3-MWCP, MalDuck, o MaCo
def extract_config(data): que será llamado por cape_utils.py y sin complicaciones.
CAPE aprovecha muchas técnicas o comportamientos de malware para permitir la captura de cargas útiles desempaquetadas:
Estos comportamientos resultarán en la captura de cargas útiles que se están inyectando, extrayendo o descomprimiendo 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 DLL en memoria. Esto es útil para muestras empaquetadas con empaquetadores simples, donde a menudo el volcado de la imagen del módulo está completamente desempaquetado.
Además de los mecanismos de desempaquetado 'pasivo' predeterminados de CAPE, es posible habilitar el desempaquetado 'activo', que utiliza puntos de interrupción para detectar escrituras en regiones de memoria recién asignadas o protegidas, con el fin de capturar cargas útiles desempaquetadas lo antes posible antes de su ejecución. Esto se habilita mediante una casilla de verificación en el envío web o especificando la opción unpacker=2 y está desactivado por defecto, ya que puede afectar la calidad de la detonación.
CAPE se puede programar mediante una firma YARA para desempaquetar empaquetadores específicos. Por ejemplo, los empaquetadores de tipo UPX son muy comunes y, aunque en CAPE estos resultan en la captura pasiva de cargas útiles desempaquetadas, la captura predeterminada se realiza después de que la carga útil desempaquetada ha comenzado a ejecutarse. Por lo tanto, al detectar empaquetadores derivados de UPX dinámicamente mediante una firma YARA personalizada y establecer un punto de interrupción en la instrucción final del empaquetador, es posible capturar la carga útil en su punto de entrada original (OEP) antes de que haya comenzado a ejecutarse.
La opción dump-on-api permite volcar 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 bypass dinámicos anti-evasivos. Dado que el malware moderno comúnmente intenta evadir el análisis dentro de los sandboxes, por ejemplo, mediante trampas de temporización para la virtualización o la detección de hooks de API, CAPE permite desarrollar contramedidas dinámicas combinando acciones del depurador dentro de firmas YARA para detectar malware evasivo a medida que detona, y realizar manipulación del flujo de control para forzar a la muestra a detonar completamente o saltar acciones evasivas.
El acceso rápido al depurador es posible con las opciones de envío bp0 a bp3, que aceptan valores RVA o VA para establecer puntos de interrupción, donde se generará una traza de instrucciones corta, gobernada por las 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 establecer la base de la imagen para puntos de interrupción RVA mediante una llamada API (por ejemplo, base-on-api=NtReadFile,bp0=0x2345).
Las opciones action0 - action3 permiten realizar acciones cuando se alcanzan los puntos de interrupción, como volcar regiones de memoria (por ejemplo, action0=dumpebx) o cambiar el flujo de control de ejecución (por ejemplo, action1=skip). La documentación de CAPE contiene más ejemplos de tales acciones.
El repositorio que contiene el código para el monitor de CAPE es distinto.
Hay un repositorio comunitario de firmas que contiene varios cientos de firmas desarrolladas por la comunidad de CAPE. Todas las nuevas características comunitarias deben enviarse a ese repositorio. Posteriormente, pueden moverse al núcleo si los desarrolladores pueden y están dispuestos a mantenerlas.
Por favor, contribuya a este proyecto ayudando a crear nuevas firmas, analizadores o bypass para más familias de malware. Actualmente hay muchas en desarrollo, así que esté atento.
Un enorme agradecimiento a @D00m3dR4v3n por portar CAPE a Python 3 en solitario.
Python3
Solo rooter debe ejecutarse como root, el resto como usuario cape. Ejecutar como root estropeará los permisos.
conf!kvm-qemu.sh y cape2.sh DEBEN ejecutarse desde una sesión de tmux para prevenir cualquier problema del sistema operativo si la conexión ssh se interrumpe.<username> con un patrón real.<WOOT> dentro!sudo ./kvm-qemu.sh all <username> 2>&1 | tee kvm-qemu.logsudo ./cape2.sh base 2>&1 | tee cape.logconf.systemctl restart <nombre_del_servicio>journalctl -u <nombre_del_servicio>-h para el menú de ayuda. Ejecutar el servicio en modo de depuración (-d) también puede ayudar.-h, pero por favor revise los scripts para entender lo que hacen.git pullpython3 utils/community.py -waf consulte -h antes para asegurarse de entendergit add --all
git commit -m '[STASH]'
git pull --rebase origin master
# corrige conflictos (rebase) si es necesario
git reset HEAD~1
# asegúrate de que el repositorio kevoreilly se haya agregado como remoto (solo necesita hacerse una vez)
git remote add kevoreilly https://github.com/kevoreilly/CAPEv2.git
# asegúrate de que todos tus cambios estén confirmados en la rama que vas a fusionar
git commit -a -m '<tu mensaje de confirmación aquí>'
# obtén cambios del repositorio kevoreilly
git fetch kevoreilly
# fusiona la rama master de kevoreilly en tu rama actual
git merge kevoreilly/master
# corrige conflictos de fusión si es necesario
# envía a tu repositorio si lo deseas
git push
Si usas CAPEv2 en tu trabajo, por favor cítalo como se especifica en el menú de GitHub "Cite this repository".
pefile ya que cada una fija la versión que quiere.
pefile ya que ya la tienes instalada. Voilà, sin más dolor.