El presente articulo explora y examina el DAIM (Defensive Advanced Intelligence Malware) preparado para reprogramar ciber-ataques ofensivos (independientemente de su naturaleza, malware/ciber-armas ofensivas, crackers, ejércitos de bots ofensivos basados en inteligencia artificial, etc.) de cara a su bloqueo, inactivación, contención y mitigación anticipada.
INTRODUCCIÓN.
El universo de los ciber-ataques (en OT, IT) crece día a día, podemos constatar: (i) Ciber-ataques a aplicaciones Web y APPs/APIs móviles con muy diversos objetivos como obtener acceso a información sensible, espionaje, beneficios, manipulación, etc. Se utilizan como vectores de ciber-ataque alteraciones de programas, inyecciones de código no autorizado, etc. El impacto al sistema es alterar, dañar, trastornar sistemas o datos, bloquear acceso, fugar información/datos del sistema, etc. El impacto a los usuarios es robar información personal (datos financieros, de salud, de su trabajo, etc.), extorsionar, falsificar o modificar datos personales, bloquear acceso o exfiltrar información sensible al público. (ii) Ciber-ataques de denegación de servicios DoS/DDoS, con muy diversos objetivos como deteriorar, debilitar e incluso impedir el acceso a sistemas/servicios. Se utilizan como vectores de ciber-ataque saturar con tráfico a un dispositivo, red, programa/software Web, etc. para ralentizar su acceso o incluso impedirlo. El impacto al sistema es bloquear redes, trastorno operacional, pérdida de servicio/acceso a finanzas, negocios, procesos industriales, etc. El impacto a los usuarios es ralentizar y bloquear redes, sistemas, servicios para impedir/degradar la productividad. (iii) Ciber-ataques de desinformación. Entre sus estrategias: distorsionar/manipular la realidad, conocimientos, eliminar datos, dividir a la sociedad, distraer (a un piloto para crear accidentes, a un sistema de control para generar desastres, etc.), generar consternación, cambiar la información/verdad (con relatos de ingeniería social, etc., cambiar votos), trastornar a las personas, crear deficiencias cognitivas, crear caos en procesos de automatización industrial, confundir, ralentizan el progreso, etc. El DAIM está capacitado para neutralizar, bloquear, inactivar, mitigar, reprogramar, etc. proactivamente anticipándose a cualquier intento de realizar todo tipo de (comportamientos previos, micro-acciones, sucesos premonitorios, micro-operaciones, funciones, procedimientos, cadenas de actividades sospechosas, micro-eventos de aviso, indicios previos, situaciones de peligro, técnicas insidiosas insinuantes, singularidades anticipadas, tácticas, síntomas, estrategias, conductas, etc. maliciosas) sobre todos los activos de nuestro mundo.

NEUTRALIZACIÓN DE SINGULARIDADES MALICIOSAS, PUNTOS DE ACTUACIÓN INSIDIOSOS E INTENTOS DE ACCIONES PERVERSAS.
El DAIM (está basado en motores de inteligencia artificial redundantes, motores de automatización y orquestación, redes neuronales profundas/convolucionales/ng-codeBert, ML, DL, IV, ID (BigD-DA), TH, ZK, ZT, NLP, modelos predictivos, playbooks, bases de conocimiento existentes y creadas por IA, modelos de tácticas-técnicas-procedimiento/TTPs, análisis de comportamiento, comprensión y adaptación al entorno, etc.). El DAIM “como un todo” es autónomo y está preparado para bloquear e impedir proactivamente todo tipo de intentos anticipadamente de actuaciones/acciones/comportamientos perversos (exploits, vulnerabilidades, micro-acciones tóxicas, etc.). El DAIM está diseñado para bloquear proactivamente/anticipadamente todo tipo de intento de “abusos syscall” (las llamadas al sistema es una forma de programación donde las peticiones del programa se hacen a un servicio del kernel del sistema operativo; esto incluye servicios relacionados con el hardware como acceso al disco local y creación y ejecución de nuevos procesos) impidiendo a los ciber-atacantes direccionar funciones del kernel sensibles utilizando funciones API que no se encuentren protegidas. El DAIM permite bloquear todo tipo de intentos de llamar a un “stub de función no sensible no monitorizado en un offset” para acceder al servicio del kernel sensible de modo que un ciber-atacante pueda evadirse de la mayor parte del software de seguridad (AVs, debuggers, etc.) y análisis sandbox. Los ciber-atacantes tratan de aprovecharse del hecho de que no todas las funciones API son “hooked” por software de seguridad, sólo funciones sensibles, además los “stubs” que se utilizan para llamar a funciones del kernel son muy similares, sólo es único el índice de la función. El sistema operativo proporciona un interfaz API (Application Programming Interface) genérico que se sitúa entre los programas normales y el sistema operativo. Bajo condiciones normales una aplicación/APP siempre llamará a un API para pedir una tarea específica del kernel. El software de seguridad coloca “hooks” sobre funciones API sensibles para interceptar y realizar comprobaciones como escaneo antimalware antes de permitir que el kernel sirva la petición. Así mismo, el DAIM permite bloquear todo tipo de intentos maliciosos de inyectar “shellcode” en el proceso objetivo antes o a la vez que explota vulnerabilidades para obtener control sobre el “puntero de instrucciones del procesador (EIP/RIP)”; la idea del ciber-atacante es ajustar el puntero de instrucciones para señalar al “shellcode” y así ejecutar y realizar su tarea maliciosa. Un “shellcode” es un fragmento pequeño de código máquina utilizado como la carga útil a la hora de explotar una vulnerabilidad software/firmware; se denomina “shellcode” debido a que históricamente debería arrancar un “command shell” desde el que el ciber-atacante puede controlar el dispositivo comprometido, pero cualquier fragmento de código que realiza una tarea similar también se denomina “shellcode”.

El DAIM está preparado para bloquear anticipadamente todo tipo de intentos de copiar ficheros sobre “Windows Admin Shares” (como ADMIN$) para impedir movimientos laterales al ciber-atacante/malware ofensivo. El DAIM está capacitado para bloquear con anticipación todo tipo de intentos de ejecutar “process hollowing” que es una técnica en la que una aplicación de confianza (como chrome.exe) se carga en el sistema sólo para actuar como un contenedor para código hostil. Un “proceso hollow” normalmente se crea en estado suspendido y seguidamente su memoria lo reemplaza por código malicioso; se enmascara bajo un proceso legítimo con lo cual puede evadir las defensas y su detección. El DAIM se encuentra preparado para bloquear anticipadamente todo tipo de intentos de LPE (Local Privilege Escalation), es decir, que un proceso con bajos privilegios pueda escalar utilizando un token robado de un proceso con mayores privilegios (esta técnica se puede utilizar en combinación con aprovecharse de vulnerabilidades para la entrega y ejecución con éxito de código malicioso de un ciber-atacante con permisos del sistema). El DAIM se encuentra capacitado para bloquear/impedir anticipadamente todo tipo de intentos de “migración de procesos” o “inyección dll reflexiva remota” que consiste en establecer presencia en un dispositivo a ciber-atacar y moverse a otro proceso para escalar privilegios o bien obtener acceso más duradero (el ciber-atacante no desea perder el control cuando un usuario final cierra su navegador Web o termina un proceso que ha sido comprometido, de modo que migra a un proceso del sistema).

El DAIM se encuentra preparado para bloquear con anticipación todo tipo de intentos de comprometer un proceso y desde allí el ciber-atacante intenta manipular otro(s) proceso(s) para cargar DLLs y ejecutar código arbitrario malicioso. El DAIM se encuentra capacitado para bloquear/impedir anticipadamente todo tipo de intentos de “inyección APC (Asynchronous Procedure Call)” lo que implica añadir código malicioso a la cola APC de un “hilo de proceso” (las funciones APC encoladas se ejecutan cuando el “hilo de proceso” entra en un estado alterado. La “inyección de código atom-bombing” es una variación que utiliza APCs para invocar código malicioso previamente escrito en la GAT (Global Atom Table)). El DAIM se encuentra preparado para bloquear con anticipación todo tipo de intentos de inyección de código utilizando una “double-agent code injection” o “abuso del Application Verifier” (“double-agent” explota una herramienta legítima de Windows denominada “Application Verifier” de Microsoft. “Double-agent” es un mecanismo malicioso aplicado sobre “Application Verifier” para que cargue código perverso en cualquier aplicación elegida incluyendo procesos Windows, etc. “Applcation Verifier” se utiliza como una herramienta de verificación runtime en aplicaciones, puede enviarse para cargar cualquier librería del disco, de modo que abre la posibilidad de cargar una librería maliciosa que dará los permisos del proceso de la víctima).

El DAIM se encuentra capacitado para bloquear/impedir anticipadamente todo tipo de intentos de inyectar “double-pulsar code injection” que utiliza un APC (Asynchronous Procedure Call) para ejecutar código malicioso (“shellcode”) dentro de un proceso confiable regular. Mitiga el método utilizado por “double-puldsar” (es parte de varios exploits como EternalBlue, EternalRomance, etc. se utiliza para auto-distribuir/implantar componente gusano en NotPetya y WannaCry) y por tanto bloquea/rompe el ciber-ataque que se basa en la misma técnica que una “inyección de código”).

El DAIM se encuentra preparado para bloquear/prohibir anticipadamente todo tipo de intentos de que un código de programa (en ediciones de Windows de 64-bits) conmute directamente de modo 32-bits a 64-bits (por ejemplo, utilizando ROP) permitiendo que la capa WoW54 realice esta transición. Microsoft proporciona compatibilidad hacia atrás de ediciones de Windows de 64-bits a software de 32-bits utilizando la capa WoW (Windows on Windows). Aspectos de la implementación WoW son útiles para ciber-atacantes ya que complica el análisis dinámico, el unpacking binario y se saltan mitigaciones de exploits. El comportamiento de una aplicación de 32-bits bajo entornos WOW-64 es diferente de un sistema verdaderamente de 32-bits. La capacidad de conmutar los modos de ejecución en “runtime” puede proporcionar al ciber-atacante métodos para la explotación, ofuscación y anti-emulación (como: “gadgets ROP” adicionales no presentes en código de 32-bits; modo de ejecución mezcla de codificadores de carga útil; características de entorno de ejecución que pueden hacer menos efectiva las mitigaciones; saltarse “hooks” insertados por el software de ciberseguridad sólo en espacio de usuario de 32-bits); la mayor parte del software de protección de puntos finales sólo “hook” funciones API sensibles en el espacio de memoria de usuario de 32-bits si un proceso se ejecuta bajo WoW-64. Si un ciber-atacante puede conmutar a modo 64-bits se obtiene acceso a versiones de 64-bis sin “hook” de funciones API sensibles que tienen “hook” en modo 32-bits. El DAIM se encuentra capacitado para bloquear anticipadamente todo tipo de intentos de escribir código malicioso en VBScript (la manipulación del flag “safemode” en VBScript en el navegador Web se denomina “VBScript God Mode”); en Windows VBScript puede utilizarse en navegadores Web o “local Shell”, cuando se usa en el navegador Web las habilidades del VBScript son restringidas por razones de ciberseguridad; esta restricción la controla el “safemode flag”; si se modifica este flag, VBScript en HTML puede hacer todo aunque está en el “local shell”. Un ejemplo un ciber-atacante/malware puede modificar el valor del “safemode flag” aprovechándose de la vulnerabilidad/bug CVE-2014-6332 causada por manejo impropio mientras se re-dimensiona un array en el motor VBScript del navegador Internet Explorer u otros navegadores Web. En “god mode” el código malicioso escrito en VBScript puede salirse del “sandbox del navegador”. Gracias al “VBScrip god mode” dejan de operar mecanismos de protección como: DEP (Data Execution Prevention), ASLR (Address Space Layout Randomozation) y CFG (Control Flow Guard). El DAIM se encuentra preparado para bloquear anticipadamente todo tipo de intentos de que los programas carguen y ejecuten DLL maliciosos contenidos en la misma carpeta como fichero de datos abiertos por dichos programas; debido a la vulnerabilidad conocida a través de diferentes nombres como: “DDL spoofing” o “DLL preloading” o “DLL hijacking” o “Binary Planting”. El DAIM se encuentra capacitado para bloquear todo tipo de intentos de utilizar DDE (Dynamic Data Exhange de Windows, se trata de un protocolo cliente-servidor para la IPC (Inter-Process Communication) entre aplicaciones) para ejecutar comandos maliciosos; por ejemplo, documentos Office de Microsoft pueden ser contaminados con comandos DDE-AUTO y utilizados para ejecutar comandos PowerShell utilizando campañas spear-phishing o contenido hospedado en sitios Web., evitando el uso de macros VBA (Visual Basic for Applications). Es posible embeber comandos DDE-AUTO en el cuerpo del mensaje de correos electrónicos o peticiones de reuniones que se ejecutan cuando se responden o aceptan en Outlook de Microsoft. El DAIM se encuentra preparado para bloquear anticipadamente todo tipo de intentos de ejecutar código malicioso utilizando DDE, así mismo bloqueará cualquier intento malicioso de crear ficheros, de leer datos de procesos y de subprocesos. El DAIM se encuentra capacitado (utilizando la característica denomina “Application Lockdown” que impide a los ciber-atacantes introducir código no deseado) para bloquear anticipadamente todo tipo de intentos de realizar capacidades maliciosas como introducir código perverso (saltándose todas protecciones de memoria y código); “Application Lockdown” bloquea los ciber-ataques que no se basan en vulnerabilidades software en aplicaciones, dichos ciber-ataques pueden utilizar macros maliciosas en documentos Office adjuntos a correos electrónicos spear-phishing. Los macros en documentos son potencialmente peligrosos ya que se crean con lenguaje de programación VBA (Visual Basic for Applicactions) que incluye la capacidad de descargar y ejecutar “binarios” de la Web y también permite utilizar PowerShell y otras aplicaciones inicialmente de confianza. El DAIM está preparado para bloquear anticipadamente todo tipo de intentos de utilizar la característica “logic-flaw exploit” que permite a los ciber-atacantes una ventaja al no necesitar explotar una vulnerabilidad software o encontrar una forma de saltarse defensas de memoria y código para infectar dispositivos de computación (los ciber-atacantes simplemente deberían abusar dicha característica-funcionalidad ofrecida por muchas aplicaciones confiables y sólo necesitan emplear ingeniería social para obligar a la víctima para que abra el documento infectado). El DAIM se encuentra capacitado para bloquear todo tipo de intentos de realizar acciones maliciosas (incluso aunque el ciber-ataque no produce un proceso hijo). El DAIM bloqueará automáticamente una aplicación basada en su comportamiento malicioso, por ejemplo, cuando una aplicación Office esta preparada para lanzar PowerShell, acceder a WMI, ejecutar una macro para instalar código perverso o manipular áreas críticas del sistema.

El DAIM se encuentra preparado para bloquear todo tipo de intentos de utilizar “exploits kits” para permitir “drive-by-downloads” de código perverso, de utilizar vulnerabilidades en JRE (Java Runtime Environment) para soltar una carga útil “Windows PE”. JRE se carga como un “plug-in” o “add-on” en navegadores Web. El DAIM se encuentra capacitado para bloquear todo tipo de intentos maliciosos de utilizar JRE (Java Runtime Environment) para ejecutar aplicaciones perversas. El DAIM bloqueará anticipadamente cualquier aplicación Java maliciosa cuando intente introducir y ejecutar un “binario Windows PE”, de modo que los ciber-atacantes no puedan abusar de Java para manipular localizaciones de auto-arranque como “startup folder”, “Run”, “RunOnce” y otras claves del Registro. Con la actualización de Java8/2014 el nivel de seguridad de las aplicaciones Java pasa a “alta”. Esto dificulta a los ciber-atacantes que ejecuten “exploits Java” con suficientes permisos para infectar, el resultado los “exploits kits” que se basan en “Java Lockdown” no sean relevantes. El DAIM se encuentra preparado para bloquear con anticipación todo tipo de intentos de ejecutar la táctica de “persistencia” y todas sus técnicas internas asociadas como “registry-run-keys” (con procedimientos internos como APT19, Briba, Badnews, etc.), “new services”, “appoint-DLLs”, etc. El DAIM se encuentra capacitado para bloquear anticipadamente todo tipo de intentos de ejecutar aplicaciones conectadas con backdoors (detecta el shellcode añadido cuando la ejecución del código no fluye a un “code cave” o a una sección añadida en el fichero PE infectado; de este modo, el DAIM protege contra herramientas maliciosas de “inyección de shellcode” como “Shellter” y “Backdoor-Factory”); el “code cave” es una técnica utilizada por los ciber-atacantes donde modifican lo que es probable software legítimo de modo que contenga una aplicación adicional. Esta aplicación adicional se inserta en lo que se denomina “code cave” es decir una sección del fichero de la aplicación objetivo que no lo utiliza el programa. Los “code cave” existen en la mayoría de las aplicaciones y el añadir código a estas secciones no rompe el comportamiento de la aplicación primaria. La ejecución de código insertado en un “code cave” suele ser un “lanzador remoto de shell” o backdoor, pueden ser muy pequeños y simplemente conceden al ciber-atacante acceso al “endpoint” (smartphone, tablet, PC, etc.) donde pueden realizar otras operaciones perversas. En este tipo de ciber-ataque se necesita que el ciber-atacante haya establecido presencia en el endpoint de modo que pueda desplegar la aplicación con backdoor o bien engaña a la víctima para que descargue e instale una aplicación que tenga el “code cave” ya explotado. Una de las razones principales de los ciber-atacantes de utilizar “code caves” es ocultarse de la detección de los usuarios y administradores víctimas. La aplicación esperada aún opera bien, pero la aplicación insertada también esta ejecutándose. Si la aplicación que se ha modificado es una herramienta legal de la organización que el administrador espera este en el dispositivo que es menos probable que la consideren como malware ofensivo si el antimalware tradicional detecta un problema. Los administradores pueden simplemente añadir en la lista de excepciones suponiendo que el motor anti-malware ha generado un falso positivo. De este modo, el ciber-atacante establece persistencia en el endpoint y puede engañar al administrador para permitir que se ejecute la aplicación insertada. Un ciber-ataque a la cadena de suministro o ecosistema de suministradores permite al ciber-atacante abrir brechas en los servidores de actualización de software en los que una actualización puede ser conectada con código perverso para silenciosamente infectar a sus clientes con cualquier tipo de malware ofensivo (como ransomware, malware con borrado profundo wipe, etc.). El DAIM se encuentra preparado para bloquear anticipadamente todo tipo de intentos maliciosos de ejecutar RDP (Remote Desktop Protocol) lo que significa bloquear todo tipo de intento de ejecutar cualquier proceso denominado “tscon.exe”, así como de bloquear todo trafico de red interna por el puerto 3389, así mismo de bloquear todo intento de ejecutar procesos producidos por “acrord32.exe”, así mismo, de bloquear todo el tráfico de red a través del puerto 22. El DAIM se encuentra capacitado para bloquear todo tipo de intentos de ejecutar “process doppelgangin” (que explota el mecanismo TxF (Transactional NTFS, esta característica del Windows permite que múltiples operaciones de fichero sean tratadas como un todo, pueden realizarse con éxito o bien pueden fallar como un todo y volverse atrás; de este modo, una aplicación puede realizar muchos cambios a muchos ficheros del disco y volver atrás todos los ficheros al estado original si se detecta un error; uno de los usos del TxF es durante la instalación de actualizaciones Windows) para ocultar malware ofensivo, elige un fichero inocente lo sobre-escribe y ejecuta el malware utilizando un API de bajo nivel, por ejemplo, para suplantar un fichero confiable (es similar al “process hollowing”); antes de ejecutar el malware rechaza y vuelve atrás todos los cambios de modo que impide que el software anti-malware escanee el contenido del fichero que realmente se ejecuta. Si se abre el fichero del disco no contendrá contenido sospechoso; además, este fichero puede ser una aplicación/APP firmada digitalmente bien conocida.

REFLEXIONES FINALES.
La ciberseguridad es un proceso transversal que integra de forma unificada/orquestada/automatizada muchas tecnologías/herramientas claves, fundamentales, prioritarias y vitales para proteger y defender todo: nuestra humanidad, medio ambiente, planeta, etc. Su carencia o deficiencia (la ciberseguridad de productos, servicios, proveedores, personas, cadenas de suministro, etc. debe estar certificada, es decir debe contar con sellos que midan su grado de ciberseguridad/madurez/resiliencia por parte de organismos homologados, competentes/oficiales) afecta negativamente, de modo que todos estamos en peligro, y no se salva nada ni nadie (seres vivos, medio ambiente, infraestructuras, sectores como electricidad, gas, petróleo, nuclear, telecomunicaciones, agua, finanzas, transportes, sanidad, etc. los cinco frentes: tierra, mar aire, espacio y ciber-espacio, este último está presente en los cuatro anteriores). Con ciberataques de desinformación y falsa bandera habrá impunidad en todo tipo de ciber-delitos al no poder saber su procedencia. Según IBM y Ponemon Institute el 40% de las empresas no revisan el código de sus APPs en busca de vulnerabilidades de ciberseguridad. El DAIM esta preparado para proteger aplicaciones/APPs y APIs en cualquier lugar donde se encuentren, desde contenedores/dockers, infraestructuras propias del cliente (on-premise), en la nube lejana (o cloud-computing), en la nube menos lejana (o fog-computing) y en el “borde” (o edge-computing). En un estudio de Thales en colaboración con IDC se destaca que sólo el 54% de los datos sensibles que se almacenan en la nube están cifrados y sólo un 44% están protegidos mediante “tokenización” para aumentar su protección.

REFERENCIAS.
- Areitio, J. “Seguridad de la Información: Redes, Informática y Sistemas de Información”. Cengage Learning-Paraninfo. 2022.
- Areitio, J. “Nuevas áreas de actuación del DAIM/MIAD contra los ciberataques ofensivos utilizando los secretos de la privacidad- ciberseguridad”. Revista Conectrónica. Nº 251. Septiembre 2022.
- Areitio, J. “Nuevos horizontes de protección y defensa proactiva del DAIM/MIAD contra todo tipo de ciberataques insidiosos”. Revista Conectrónica. Nº 252. Octubre 2022.
- Areitio, J. “Exploración multidimensional y multipolar del malware ofensivo”. Revista Conectrónica. Nº 253. Noviembre 2022.
- Stamp, M., Alazab, M. and Shalaginov, A. “Malware Analysis Using Artificial Intelligence and Deep Learning”. Springer. 2021.
- Jhanjhi, N.Z., Hussain, K., Humayun, M. and Abdullah, A.B. “Information Security Handbook (Internet of Everything (IoE)). CRC Press. 2022.
- Flow, S. “How to Hack Like a Ghost: Breaching the Cloud”. No Starch Press. 2021.
- Batina, L., Bäck, T., Buhan, I. and Picek, S. “Security and Artificial Intelligence: A Crossdisciplinary Approach”. Springer. 2022.
- Savas, O. and Deng, J. “Big Data Analytics in Cybersecurity (Data Analytics Applications)”. Routledge. 2021.
- Hettema, H. “Agile Security Operations: Engineering for Agility in Cyber Defense, Detection, and Response”. Packt Publishing. 2022.
- Payne, B. “Go H*ck Yourself: A Simple Introduction to Cyber Attacks and Defense”. No Starch Press. 2022.
- Tagarev. T., Atanassov, K.T., Kharchenko, V. and Kacprzyk, J. “Digital Transformation, Cyber Security and Resilience of Modern Societies”. Springer. 2022.

Autor: Prof. Dr. Javier Areitio Bertolín     -      Director del Grupo de Investigación Redes y Sistemas