alex@root:~$

Archive

About

RSS

Manual De Buenas Practicas Para El Desarrollo De Malware De La Cia

El siguiente manual fue extraído de la gran filtración de la CIA “Vault 7” por parte de Wikileaks en el año 2017, las técnicas empleadas en el siguiente Post son muy actuales y pueden seguirse al pie de la letra sin ningún problema. El manual de la CIA esta muy bien escrito y detallado, no solo se explica el QUE HACER si no también el PORQUE, gózalo y Happy Hacking!!!

Consejos Generales

  • Ofusque o encripte todas las cadenas y los datos de configuración que se relacionen directamente con la funcionalidad de la herramienta. También se debe considerar la posibilidad de desofuscar las cadenas en la memoria únicamente en el momento en que se necesitan los datos. Cuando un valor desofuscado previamente ya no sea necesario, se debe borrar de la memoria. Justificación: Los datos de cadenas y/o de configuración son muy útiles para analistas y técnicos de ingeniería inversa.

  • NO descifre ni desofusque todos los datos de tipo STRING o de configuración inmediatamente después de la ejecución. Justificación: aumenta la dificultad del análisis dinámico automatizado del binario para encontrar datos confidenciales.

  • Elimine explícitamente los datos confidenciales (claves de cifrado, datos recopilados sin procesar, código shell, módulos cargados, etc.) de la memoria tan pronto como ya no se necesiten los datos en formato de STRING sin formato. NO CONFÍE EN QUE EL SISTEMA OPERATIVO HAGA ESTO AL TERMINAR LA EJECUCIÓN. Justificación: aumenta la dificultad para la respuesta a incidentes y la revisión forense.

  • USE una clave única en el momento de la implementación para ofuscar/desofuscar STRINGS confidenciales y datos de configuración. Justificación: plantea la dificultad de analizar múltiples implementaciones de la misma herramienta.

  • Elimine toda la información de símbolos de depuración, manifiestos (MSVC artifact), rutas de compilación y nombres de usuario de desarrolladores de la compilación final de un binario. Justificación: aumenta la dificultad para el análisis y la ingeniería inversa, y elimina los artefactos utilizados para la atribución/origen.

  • Elimine toda la salida de depuración (por ejemplo, llamadas a printf(), OutputDebugString(), etc.) de la compilación final de una herramienta.
    Justificación: aumenta la dificultad para el análisis y la ingeniería inversa.

  • NO importe ni llame explícitamente funciones que no sean coherentes con la funcionalidad manifiesta de una herramienta (es decir, WriteProcessMemory, VirtualAlloc, CreateRemoteThread, etc., para archivos binarios que se supone que son un reemplazo del bloc de notas).
    Justificación: reduce el posible escrutinio del binario y aumenta ligeramente la dificultad del análisis estático y la ingeniería inversa.

  • NO genere archivos de volcado de memoria, archivos de volcado de memoria, pantallas “azules”, Dr Watson u otros cuadros de diálogo emergentes y/u otros artefactos en caso de que se bloquee un programa. INTENTE forzar un bloqueo del programa durante las pruebas unitarias para verificar esto correctamente.
    Justificación: evita sospechas por parte del usuario final y los administradores del sistema y aumenta la dificultad para la respuesta a incidentes y la ingeniería inversa.

  • NO genere archivos de volcado de memoria (crashdump), archivos de volcado de memoria, pantallazos “azules”, Dr Watson u otros cuadros de diálogo emergentes y/u otros artefactos en caso de que se bloquee un programa. INTENTE forzar un bloqueo del programa durante las pruebas unitarias para verificar esto correctamente. Justificación: evita sospechas por parte del usuario final y los administradores del sistema y aumenta la dificultad para la respuesta a incidentes y la ingeniería inversa.

  • NO realice operaciones que hagan que la computadora de destino no responda al usuario (por ejemplo, picos de CPU, parpadeos en la pantalla, “congelamiento” de la pantalla, etc.). Justificación: evita que el usuario o el administrador del sistema presten atención no deseada a la existencia y el comportamiento de la herramienta.

  • Realice todos los esfuerzos razonables para minimizar el tamaño de los archivos binarios que se cargarán en un destino remoto (sin usar compresores ni compresión). Los tamaños ideales de los archivos binarios deberían ser inferiores a 150 KB para una herramienta con todas las funciones. Justificación: acorta el “tiempo en el aire” general, no solo para que la herramienta llegue al objetivo, sino también el tiempo para ejecutar la funcionalidad y la limpieza.

  • PROPORCIONE un medio para “desinstalar”/”eliminar” por completo implantes, funciones Hooks, subprocesos inyectados, archivos eliminados, claves de registro, servicios, procesos bifurcados, etc. siempre que sea posible. Documente explícitamente (incluso si la documentación dice “No hay desinstalación para este“) los procedimientos, permisos necesarios y efectos secundarios de la eliminación. Fundamento: Evita que se dejen datos no deseados en el objetivo. Además, una documentación adecuada permite a los operadores realizar una mejor evaluación de los riesgos operativos y comprender plenamente las implicaciones del uso de una herramienta o de una característica específica de una herramienta.

  • NO deje fechas/horas como marcas de tiempo de compilación, marcas de tiempo del enlazador, tiempos de construcción, tiempos de acceso, etc. que se correlacionen con el horario laboral general de EE. UU. (es decir, de 8 a. m. a 6 p. m., hora del Este). Justificación: Evita la correlación directa con el origen en Estados Unidos.

  • NO deje datos en un archivo binario que demuestre la participación de la CIA, el USG o sus empresas asociadas voluntarias en la creación o el uso del binario/herramienta. Justificación: La atribución de un valor binario, herramienta, etc. por parte de un adversario puede causar impactos irreversibles en las operaciones y acciones pasadas, presentes y futuras del USG.

  • NO tenga datos que contengan términos de cobertura, compartimentos, nombres de códigos de operación u otra terminología específica de la CIA y el USG en el binario. Justificación: La atribución de un valor binario, herramienta, etc. por parte de un adversario puede causar impactos irreversibles en las operaciones y acciones pasadas, presentes y futuras del USG.

  • NO tenga “palabras sucias” (ver lista de palabras sucias – TBD) en el binario. Justificación: Las palabras sucias, como los términos hackers, pueden provocar un escrutinio injustificado del archivo binario en cuestión.

Redes

  • Utilice cifrado de extremo a extremo para todas las comunicaciones de red. NUNCA utilice protocolos de red que infrinjan el principio de extremo a extremo en lo que respecta al cifrado del Payload. Justificación: obstaculiza el análisis del tráfico de la red y evita la exposición de datos operativos y de recopilación.

  • NO confíe únicamente en SSL/TLS para proteger los datos en tránsito. Justificación: Numerosos vectores de ataque tipo “man-in-middle” y fallas divulgadas públicamente en el protocolo.

  • NO permita que el tráfico de red, como los paquetes C2, se pueda reproducir. Justificación: Protege la integridad de los activos operativos.

  • Utilice protocolos de red compatibles con RFC de ITEF como capa de combinación. Los datos reales, que deben cifrarse durante el tránsito por la red, deben canalizarse a través de un protocolo conocido y estandarizado (por ejemplo, HTTPS). Justificación: Los protocolos personalizados pueden resultar llamativos para los analistas de redes y los filtros IDS

  • Realice una limpieza adecuada de las conexiones de red. NO deje conexiones de red obsoletas. Justificación: aumenta la dificultad del análisis de la red y la respuesta a incidentes.

Entrada/Salida Disco

  • DOCUMENTE explícitamente la “huella forense del disco” que podrían crear potencialmente varias características de un binario/herramienta en un objetivo remoto. Justificación: Permite mejores evaluaciones de riesgo operativo con conocimiento de posibles artefactos forenses del sistema de archivos.

  • NO lea, escriba ni almacene en caché datos en el disco innecesariamente. Tenga cuidado con el código de terceros que puede escribir o almacenar en caché datos en el disco de manera implícita. Justificación: Reduce la posibilidad de que aparezcan artefactos forenses y posibles firmas.

  • NO escriba datos de recopilación en texto sin formato en el disco. Justificación: Aumenta la dificultad de respuesta a incidentes y de análisis forense.

  • Cifre todos los datos escritos en el disco. Justificación: oculta la intención del archivo (recopilación, código confidencial, etc.) y aumenta la dificultad del análisis forense y la respuesta a incidentes.

  • Utilice un borrado seguro al eliminar un archivo del disco que borre como mínimo el nombre del archivo, las marcas de fecha y hora (creación, modificación y acceso) y su contenido. (Nota: La definición de “borrado seguro” varía de un sistema de archivos a otro, pero se debe realizar al menos una pasada de ceros de los datos. El énfasis aquí está en eliminar todos los artefactos del sistema de archivos que podrían ser útiles durante el análisis forense) Justificación: Aumenta la dificultad de respuesta a incidentes y de análisis forense.

  • NO realice operaciones de E/S de disco que provoquen que el sistema deje de responder al usuario o alerte a un administrador del sistema. Justificación: evita que el usuario o el administrador del sistema presten atención no deseada a la existencia y el comportamiento de la herramienta.

  • NO utilice un “encabezado/pie de página mágico” para los archivos cifrados que se escriban en el disco. Todos los archivos cifrados deben ser archivos de datos completamente opacos. Justificación: evita la firma de valores mágicos de formatos de archivos personalizados.

  • NO utilice nombres de archivo ni rutas de archivo codificados de forma rígida al escribir archivos en el disco. El operador debe poder configurar esto en el momento de la implementación. Justificación: Permite al operador elegir el nombre de archivo adecuado que se ajuste al objetivo operativo.

  • NO utilice nombres de archivo ni rutas de archivo codificados de forma rígida al escribir archivos en el disco. El operador debe poder configurar esto en el momento de la implementación. Justificación: Permite al operador elegir el nombre de archivo adecuado que se ajuste al objetivo operativo.

Fechas/Hora:

  • Utilice GMT/UTC/Zulu como zona horaria al comparar fecha/hora. Justificación: proporciona un comportamiento consistente y ayuda a garantizar que los “disparadores/balizas/etc.” se activen cuando se espera.

  • NO utilice formatos de marca de tiempo centrados en EE. UU., como MM-DD-AAAA. Generalmente se prefiere AAAAMMDD. Justificación: mantiene la coherencia entre las herramientas y evita asociaciones con Estados Unidos.

    Fuente:

    https://wikileaks.org/ciav7p1/cms/page_14587109.html