Esta semana, en mitad de la vorágine de viajes y charlas, en mi buzón de MyPublicInbox he recibido un par de correos muy similares. Ambos eran de incidentes de seguridad en PYMEs, y ambos tenían un punto de desesperación por culpa de un incidente de seguridad. Se trataba de dos ciberestafas - nada nuevas - que habían robado el dinero de sus cuentas.
El primero de ellos tenía un troyano en el equipo desde donde le controlaban el correo electrónico, y le estaban controlando las transferencias bancarias, desde el correo electrónico. Es una técnica que ya os conté hace más de doce años, donde se modifican los números de cuenta, y la víctima acaba siendo ella la que envía el dinero a cuentas en el extranjero pensando que lo está haciendo a una cuenta correcta.
El segundo de los correos fue un ransomware que le estaba pidiendo un pago en BitCoins para devolverle el acceso a todos sus documentos, trabajos, facturas, bases de datos de claves de acceso a cuentas, etcétera. Nada nuevo bajo el sol en ninguno de los dos ataques.
Por supuesto, yo les contesté con la mejor de mis intenciones, explicándole al primero la dificultad de recuperar el dinero enviado hace una semana a unas cuentas en Hong-Kong, y al segundo lo complejo que es recuperar a corto plazo de tiempo el acceso a esos documentos sin pagar, y los costes que puede tener intentar crackear el cifrado del ransomware por fuerza bruta.
Sin embargo, lo que más me llamó la atención era el punto de desesperación y sufrimiento que ambas personas tenían en sus mensajes. Eran PYMEs y estos ataques les hacían un roto para seguir con su vida normal, para poder hacer frente a los pagos del mes, y les afectaba a su vida personal de manera importante. Las pequeñas empresas eran, y son su forma de vida. Viven al mes de lo que van cobrando y la disrupción les dejaba en una situación crítica y desesperanzada.
Los servicios de ciberseguridad son caros o baratos dependiendo de ti
A veces me gustaría poder hacer magia, y con un golpe de teclado hacer que el dinero regresara de las cuentas de los cibercriminales o que los ficheros se descifraran con un sencillo script hecho con Vibe Coding, pero la realidad es que la solución no está después, si no antes. Ninguna de ellos tenía sistemas de protección en tiempo real. No tenían EDRs para detectar el malware y las vulnerabilidades cuando llegaban.
"¡Es que los servicios de ciberseguridad son muy caros!",
me decía una de las víctimas. Sí, es verdad. A posteriori, los servicios de ciberseguridad son muy caros, porque los analistas forenses o los expertos de ciberseguridad si los pagas por horas cuando ya has tenido el problema, te van a costar mucho, y encima no van a poder hacer magia. Pero poner soluciones de prevención de ciberseguridad ANTES es muy barato.
El modelo de seguridad de IronGate Cybersecurity funciona como una Suscripción por Dispositivo, donde se da un servicio MDR (Managed Detection and Response) que vela por la seguridad de los equipos las 24 horas del día, los 7 días a la semana, ayudando a PyMes, Autónomos y Particulares a tener protegidos los equipos, detectar las amenazas y tomar las acciones preventivas y/o correctivas de ciberseguridad adecuadas a la alerta. Por 10 € al mes por equipo.
Para ello, IronGate Cybersecurity se encarga de ser un Security Operations Center para que todas alarmas de seguridad generadas desde tus sistemas de seguridad en los dispositivos sirvan para aumentar el nivel de seguridad de tus equipos. En una PYME con dos ordenadores y tres móviles el coste de la protección con EDRs y MDR es de 50 € al mes con monitorización 24x7. La cantidad de dinero perdida en los dos incidentes que os he contado podría pagar la protección de los sistemas por toda la vida útil de la emrpesa.
Sé que "gastar" en seguridad es algo que nunca viene bien cuando eres una PYME que va al día, pero mejor un poco en prevención que sufrir las consecuencias después. Os garantizo que una vez que el dinero ha volado o que el ransomware ha cifrado los archivos, los expertos de ciberseguridad no van a poder hacer magia. Si tu pequeña empresa es tu forma de subsistir, entonces no ahorres en lo importante.
Pero claro, Microsoft ha fortificado el entorno OAuth, y ha añadido mejoras de seguridad para el registro de aplicaciones - tanto internas como externas - y para la concesión de tokens por parte de los usuarios a estas aplicaciones, como bien se explica en el artículo.
Las mejoras se incluyeron en el año 2020, y este mismo año se añadió la opción de dejar que Microsoft decidiera quién puede o no puede conceder un Token OAuth, quedando aún algunas excepciones para usuarios administradores, y para ataques internos entre usuarios del mismo Tenant. Esto es algo que Microsoft piensa fortificar también en breve como podéis ver en el anuncio que ya ha hecho.
En cualquier caso, utilizando la plataforma de CoPilot, se puede crear una aplicación registrada tanto externa como internamente que, usando una aplicación en forma de asistente, robe los Tokens OAuth de sus víctimas con una web que ofrece toda la confianza a los usuarios. La web de Copilot para assistentes.
Si este Asistente es una web maliciosa, puede solicitar la autenticación mediante Tokens OAuth que pidan acceso excesivo a los ficheros, mensajes, calendario, etcétera. Esto, como explicamos en los artículos de Sappo, se basa en solicitar el Token OAuth con un Scope excesivo que permita hacer de todo en la identidad del usuario.
El Bot registra un Copilot Agent que pide muchos privilegios en forma de Token OAuth, y luego cuando el usuario se autentica - en la plataforma de Bots es necesario hacerlo con un 2FA basado en un número -, el sistema generar un Token que el Malicious CoPilot Agent filtra al atacante.
En la imagen de arriba se ve cómo sería la pantalla de origen donde se solicitan los permisos cuando el asistente ha sido registrado en el mismo Tenant por un usuario interno y está atacando a un usuario interno. Y en la imagen siguiente, lo mismo, pero con una asistente registrado en un Tenant externo para atacar a los administradores - que siguen teniendo la opción por defecto de conceder Tokens OAuth -.
Al final, estos dos entornos se deben a las restricciones que por defecto añadió en 2020 y en 2025Microsoft para reducir la superficie de exposición de los usuarios a este tipo de ataques de robo de TokensOAuth con app maliciosas, pero como se explica al principio siguen quedando opciones para atacar a los usuarios de estas dos maneras.
En cualquier caso, la URL donde están publicadas las aplicaciones es de confianza, ya que es la URL de un dominio de Copilot de Microsoft. Y una vez que el usuario se autentique con el Bot Framework, con el token numérico, entonces ya tendremos el Token OAuth generado para compartir con el atacante.
El resto es ya lo conocido, el Malicious Copilot Agent es capaz de acceder al Token OAuth que ha sido creado como. parte del proceso de login con una cantidad de permisos que da un poder enorme a la aplicación sobre la identidad del usuario, para hacer las maldades ya conocidas.
La magia es que para hacer este Malicous CoPilot lo puedes hacer con el asistente NoCode/LowCode de Microsoft CoPilot, creando todos los flujos, y con un trigger en el proceso de Login donde se puede añadir un workflow especial para robar el Token OAuth.
Como se puede ver en la imagen siguiente, en el diseño del Workflow tenemos acceso al Token OAuth con el que se hace Sign-in, y este Token OAuth es el que se va a enviar con una petición a servidor HTTP controlado por el atacante.
Aquí se ve cómo se hace el flujo para que se haga la petición a un HTTP Server con una Key que tiene como Value el UserAccessToken. Y la URL del servidor controlado por el atacante. Ahora solo falta configurar los permisos se quieren en ese Token OAuth para permitir el acceso al Malicious CoPilot y la app para poder publicarla.
Una vez creado el asistente con los flujos, hay que registrar la app, como podéis ver en la siguiente pantalla, donde se configura la aplicación en el tenant.
El resto, es hacer las maldades que se quieran con el Token OAuth robado al usuario. Lo curioso de esta técnica es que se ha utilizado la infraestructura de Microsoft CoPilot para saltarse las restricciones contra las apps maliciosas - como las que usamos nosotros en Sappo - para robar Tokens OAuth. Muy chulo.
Esta es la pregunta que más me han hecho desde que comenzó el apagón eléctrico de la historia de España. La respuesta no la sabremos hasta que los equipos que están investigando el incidente hayan podido analizar "Root Cause" del incidente, y para ello van a necesitar tiempo. Y lo más importante es recuperar la energía lo antes posible, que hay muchos sitios críticos donde la existencia de la energía puede salvar vidas.
Figura 1: ¿Podría ser el Apagón Eléctrico de España un ciberataque?
¿Podría haber sido un ciberataque? Pues no lo sabemos aún, y no seré yo el que vaya a especular sobre esto, pero es una de las posibilidades que podrían ser, por supuesto. Pero también podrían ser otras las causas que han producido esto, así que lo mejor es no especular y esperar a ver lo que los forenses que estén en el CSIRT ahora nos digan cuando tengan los datos.
Al final, en el pasado hemos visto caídas de sistemas de Internet, de energía, de llamadas, de gas, y de casi cualquier suministro crítico por causas que puedan interrumpir el sistema que distribuyen la luz, el gas, las redes de telefonía o datos. Y ahora no sabemos más que puede ser cualquier de ellos.
Las causas posibles, os las podéis imaginar:
Accidente: Un incendio, una inundación, una nevada, un volcán. De todo esto hemos vivido en los años recientes con Filomena, la Dana, el Volcán de La Palma, o los Incendios que nos han asolado durante mucho años parte de nuestro territorio. Estos suelen producir cortes locales, o puntuales, porque destrozan partes del sistema, pero no han solido ser nacionales porque no han tocado el corazón del sistema, y cuando se diseña un sistema crítico es necesario redundar las partes core que pueden discontinuar el sistema.
Pero puede ser de gran intensidad o tocar un punto clave. Durante la Dana, hubo que hacer un trabajo especial para reforzar los centros de llamadas del 112 que estaban saturados, y que fue una de las prioridades durante la crisis, ya que no podían atender tantas llamadas. Que se pudieran atender todas las llamadas de emergencia lo antes posible, y para eso hubo que re-enrutar comunicaciones a centros de respaldo en otras ubicaciones.
Pero los ha habido mucho más cercanos en el tiempo .En el año 2023 se alertó del ataque al sector eléctrico de Dinamarca, donde más de dos docenas de centrales fueron afectadas en tres oleadas, lo que deja claro que fue un ataque coordinado y organizado contra una infraestructura crítica de un país.
Ahora mismo no sabemos nada. Serán los expertos que estén analizando el caso los que tengan que dar las informaciones, así que todo son especulaciones, por lo que hay que evitar caer en asegurar nada, porque solo los que tengan los datos tienen la información. Lo que sí que está claro es que algo ha pasado en el sistema y hay que saber qué es para que no vuelva a pasar.
Con la nueva actualización Sergio de los Santos ha querido meterle una revisión profunda desde la que realizó en el año 2020 y hacer una edición muy especial con motivo de alcanzar los 5.000 ejemplares vendidos de este título, que es un "superventas" de nuestra pequeña editorial 0xWord.
En el caso de "Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición" actualizada con nuevos contenidos, el índice ha cambiado bastante, ya que si bien las secciones han cambiado poco, los detalles han ido cambiando radicalmente en este texto actualizado a día de hoy. Aquí lo tienes.
Usar tus Tempos de MyPublicInbox 0xWord para adquirir este libro
La idea es muy sencilla, hemos creado un Buzón Público de 0xWord en MyPublicInbox y tenemos disponible el módulo de transferencias de Tempos entre cuentas siempre que el destinatario sea un Perfil Público de la plataforma. Para que se puedan hacer estas transferencias, primero debe estar el Perfil Público destinatario de la transferencia en la Agenda.
Una vez que lo tengas en la agenda, ya será tan fácil como irte a tu perfil - se accede haciendo clic en la imagen redonda con tu foto en la parte superior - y entrar en la Zona de Transferencias. Desde allí seleccionas el Buzón Público de 0xWord, el número de Tempos que quieres transferir, y en el concepto debes poner que es para recibir un código descuento para usar en la tienda de 0xWord.
No te preocupes por el texto concreto, porque los procesamos manualmente como los pedidos de se hacen en la tienda.
Canjear 500 Tempos por un código descuento de 5 €
La última opción es bastante sencilla. Solo debes irte a la sección de Canjear Tempos -> Vales para Tiendas, y "Comprar" por 500 Tempos y código de 5 €. Es lo mismo que enviar la transferencia pero en un paquete de 500 Tempos y de forma totalmente automatizada, así que solo con que le des a comprar recibirás el código descuento y lo podrás utilizar en la tienda de 0xWord.com
Así que, si quieres conseguir nuestros libros de Seguridad Informática & Hacking aprovechando los Tempos de MyPublicInbox podrás hacerlo de forma muy sencilla y mucho, mucho, mucho más barato. Y así apoyas este proyecto tan bonito que es 0xWord.com.
Ser escritor de libros de 0xWord
Además, todos lo que queráis convertiros en escritores y hacer un proyecto de libro con nosotros. Podéis también enviarnos vuestra propuesta a través del buzón de 0xWord en MyPublicInbox, y si sois Perfiles Públicos de la plataforma, podéis entrar en la sección de Mi Perfil -> Servicios para ti y solicitar más información sobre el proceso de escribir un libro en 0xWord.
Nuestro equipo se pondrá en contacto contigo y evaluará tu proyecto de publicación de libro. Ya sabes que principalmente de Seguridad Informática & Hacking, y puede ser técnico, súper-técnico, o divulgación, y si es una novela... podemos estudiarlo también.
Se dice que toda información puede ser un arma de doble filo, y los registros de Windows no son la excepción. Con la evolución de la informática, los sistemas y la programación a lo largo de las décadas, el registro de eventos se ha convertido en un recurso esencial. Esto es tanto para mantener la seguridad y estabilidad de un sistema, como cuenta Sergio de lo Santos en su libro "Máxima Seguridad en Windows: Secretos Técnicos" como para descubrir las tácticas de aquellos que buscan infiltrarse en él, como hace el Malware Moderno.
Hoy en este artículo, exploraremos en profundidad la naturaleza de los logs de Windows, cómo interpretarlos, y cómo extraer información valiosa haciendo uso de Python, entre otras herramientas. Además, descubriremos cómo los “malos” emplean estos registros para ocultar su malware, mientras que los “buenos” los utilizan para detectar y prevenir amenazas.
¿Qué son los logs de Windows?
El visor de eventos es un componente de los sistemas operativos Windows que permite a administradores y usuarios ver lo que pasa en un sistema. Todas las acciones realizadas en Windows quedan registradas de forma que mediante el visor de eventos se puedan leer.
Por ejemplo, cuando iniciamos sesión, el código que se ejecuta en las entrañas de nuestro sistema, a su vez, deja un rastro por donde ha pasado; y, por ende, por donde hemos pasado nosotros como usuarios. Gracias a los registros de Windows, podemos saber en qué momento y donde se ejecutó un binario especifico y que procesos desencadenó el mismo.
Figura 4: Registros EVTX en la carpeta C:\Windows\System32\winevt\Logs
Si visitamos esta ruta (C:\Windows\System32\winevt\Logs) en nuestro sistema, podremos multitud de ficheros, cada uno de ellos se trata de un fichero de logs relativo a un módulo de nuestro sistema. Por ejemplo, vemos Powershell, HyperV, NTFS, etcétera. Sin embargo, existen tres ficheros de logs, esenciales, comunes al resto que son:
Seguridad: Eventos relacionados con la seguridad del sistema, como inicios de sesión de usuarios, intentos de acceso no autorizado, cambios en políticas de seguridad y otras actividades de seguridad.
Aplicaciones: Eventos generados por aplicaciones y servicios instalados en el sistema. Estos registros pueden incluir errores de aplicaciones, advertencias y eventos informativos relacionados con aplicaciones específicas.
Sistema: Eventos relacionados con el funcionamiento del sistema operativo en sí, como fallos de hardware, problemas de inicio del sistema, cambios en la configuración del sistema, entre otros.
Al examinar detenidamente estos archivos, notamos que su extensión es "EVTX". Esta extensión se refiere al formato Windows XML EventLog, que Windows utiliza para almacenar información desde que se introdujo por primera vez en Windows Vista y Windows Server 2008. Desde entonces, se incluye en todas las versiones. Cada evento en una entrada de logs contiene la siguiente información:
Nivel: Gravedad del evento (information, critical, warning, error, verbose).
Fecha: Fecha en que ocurrió un evento.
Hora: Hora en que ocurrió un evento.
Origen: Programa o componente que causó el evento.
Categoría de tarea: Tipo de registro de evento registrado.
Usuario: Nombre de usuario del usuario conectado a la máquina cuando ocurrió el evento.
Computadora: Nombre de la computadora.
Que estos archivos tengan este formato permite al visor de eventos tres principales ventajas frente a otros formatos: Rollover (se divide en fragmentos y los nuevos fragmentos pueden sobrescribir los antiguos limitando el tamaño máximo), compresión (como veremos más adelante, si convertimos con Python, el fichero de EVTX a JSON, el tamaño pasa de 18,5 MB a más de 60 MB, lo que significa un aumento del 324% de su tamaño) y uso de tipos sólidos (permite filtrar y seleccionar con rapidez los eventos, evitando tener que recorrer todo el archivo).
Figura 5: Comparación del contenido de un fichero EVTX
en crudo y convertido a formato JSON
De forma nativas, se pueden visualizar los archivos EVTX, haciendo uso del visor de eventos de Windows (eventvwr), el cual incluye funcionalidades como filtrado, búsqueda avanzada, vistas personalizadas, suscripción a eventos, entre otros.
El doble filo de los registros de eventos de Windows: Anatomía de amenazas y herramientas de defensa
Las estafas que se valen de los eventos de Windows como anzuelo para engañar a los usuarios han sido notorias. En el pasado, hubo casos de llamadas de supuestos técnicos de "Microsoft" que dirigían a las personas a ver registros de eventos con errores triviales para dar credibilidad a la estafa.
En una técnica más sofisticada, se descubrió que los registros de eventos de Windows, específicamente en los registros de Key Management Services (KMS), se usaron como escondite para ocultar código malicioso.
Esto se lograba inyectando "shellcode" en estos registros, aprovechando la carga de código malicioso mediante la manipulación de archivos legítimos del sistema. Si quieres ampliar la información sobre esta técnica, puedes visitar el artículo de SecureList by Kaspersky que habla de ello.
Pero no todo es negativo: estos eventos de Windows también han sido vitales para combatir el malware y ransomware. Los investigadores de seguridad hacen uso a menudo de estos registros —entre otros— para rastrear, entender y desarrollar herramientas que descifren y reviertan los daños causados por estos ataques, proporcionando soluciones para desbloquear archivos afectados.
Figura 9: Trazas de algunos eventos ejecutados por un malware o actor malicioso
En un ataque ransomware, podríamos observar algunos logs como los siguientes, donde el actor hace uso de ScreenContent.ClientService.exe para transferir archivos y ejecutar comandos maliciosos, esto podría indicarnos la etapa inicial del ataque.
Manipular y automatizar la seguridad a partir de los eventos de Windows
Previamente, mencionamos que los archivos EVTX pueden ser visualizados y manipulados desde el visor de eventos de Windows. Aunque este cuenta con muchas características útiles, es importante considerar las limitaciones del visor de eventos, como la falta de replicación de registros entre computadoras en una red y la dificultad para agregar registros de múltiples sistemas.
Por esta razón, vamos a explorar cómo exprimir la monitorización de eventos en tu sistema o red corporativa al máximo, ya que es posible manipular los eventos mediante el uso de Python y/u otras herramientas disponibles. Vamos al turrón:
Stack ELK
El conjunto de herramientas del stack ELK, compuesto por Elasticsearch, Logstash y Kibana, proporciona una solución robusta y flexible para la recopilación, análisis y visualización de datos, incluidos los eventos de Windows. Esta combinación potente permite la manipulación eficiente de eventos y la automatización de los registros de eventos de Windows.
Sin embargo, eso no sería posible sin Winlogbeat, se trata de un agente ligero y eficiente diseñado para enviar registros de eventos desde sistemas Windows a Elasticsearch o Logstash para su análisis posterior. Su capacidad para leer eventos de varios registros, filtrarlos según criterios definidos por el usuario y enviar los datos a los destinos configurados lo convierte en una herramienta fundamental en la monitorización de eventos en entornos Windows. La instalación de Winlogbeat es sencilla:
A continuación, en una ventana de Powershell como administrador se ejecuta el script de instalación: “.\install-service-winlogbeat.ps1”
Es importante configurar adecuadamente las conexiones a Elasticsearch o Logstash en el archivo de configuración winlogbeat.yml. Para ello, puedes encontrar más información en la documentación de Winlogbeat
Por último, para iniciar Winlogbeat, ejecuta el siguiente comando: “net start winlogbeat”
Una vez que los eventos de Windows se han indexado en Elasticsearch, podemos usar Kibana para visualizarlos y Python para interactuar con ellos. Las bibliotecas como elasticsearch-py nos permiten realizar consultas avanzadas a Elasticsearch desde Python, lo que facilita el análisis y la manipulación de los datos. Esto nos permite llevar el análisis de los eventos de Windows hasta el límite de lo que podamos imaginar.
python-evtx
Otra alternativa a Winlogbeat y ELK es crear nuestro propio agente mediante el uso de la librería python-evtx, que nos permite analizar y manipular eventos de Windows. Se trata de una biblioteca de Python que permite acceder a la estructura interna de los archivos EVTX, los cuales contienen los registros de eventos de Windows y volcar los datos correspondientes en un fichero JSON (como el que veíamos al comienzo de este artículo). Con unas pocas líneas podremos hacer uso de python-evtx, previa instalación con “pip install python-evtx xmltodict”. Puedes comenzar a analizar eventos de Windows utilizando el ejemplo de la imagen siguiente.
Figura 12: Ejemplo de código para convertir de forma
simple un fichero EVTX a formato JSON
Estas son solo algunas de las posibilidades que ofrece python-evtx para analizar y manipular eventos de Windows. Para realizar análisis más complejos, crear herramientas personalizadas para la monitorización de eventos o automatizar tareas, visita su repositorio para conocer más.
Conclusión
En resumen, los registros de eventos de Windows son una fuente invaluable de información, revelando tanto la salud del sistema como posibles amenazas. Aunque han sido utilizados para esconder y ejecutar malware, también son la clave para la detección y defensa contra ataques. Herramientas como ELK y python-evtx ofrecen formas poderosas de interpretar y manipular estos registros, permitiendo análisis detallados y protección proactiva.
Me ha gustado mucho el trabajo de DoubleDrive, presentado por el investigador Or Yair (@oryair1999) en la presente BlackHat USA 2023, en el que ha explicado cómo se puede convertir al proceso de OneDrive en tu equipo en un agente doble que trabaje para un Ransomware y cifre todos los archivos de tu equipo. Una idea que ya hemos explorado nosotros en el pasado con RansomCloud, pero que aquí utiliza una aproximación diferente, y me ha encantado.
Figura 1: DobuleDrive. Cómo OneDrive se puede convertir en un Agente Doble
y trabajar para un Ransomware
Antes de contaros un poco sobre la investigación, dejadme hacer una pequeña introducción a lo que nosotros construimos y exploramos en hace ya unos años.
Ransomcloud O365
Cuando en el año 2016 nosotros creamos Sappo para robar tokens OAuth de servicios como Google, Office 365 o OneDrive, uno de los escenarios que exploramos fue el de crear un Ransomware que cifrara todo tu contenido en la nube. Que cifrara tus archivos de OneDrive en la nube, que cifrara tus correos electrónicos de Office365, que te dejara sin ningún contenido del que disponías.
De este ataque, Kevin Mitnick, que lo utilizó en muchas de sus conferencias, hizo vídeos explicando el proceso donde lo dejaba bastante claro. El objetivo, tan sencillo como cifrar el contenido que hubiera en la nube, y que se sincronice con lo que haya en local. Listo.
DoubleDrive OneDrive
La idea con el ataque de DoubleDrive, presentado por Or Yamir, es un poco diferente, aunque tiene similitudes con nuestro ataque. En este caso se trata de cómo un Ransomware puede evitar ser detectado por medio de patrones de comportamiento, que es lo que utilizan muchos de los agentes EDR(Endpoint Detection and Response) que protegen al sistema operativo contra procesos maliciosos que generan actividad típica de un ransomware.
Lo que la investigación predice es que este tipo de técnicas pueden ser utilizadas dentro de poco por Malware Moderno ( y basta con leerse el libro de Sergio de los Santos para tener claro que lo harán), con el objetivo de evitar la detección. En este caso, la idea es utilizar el agente de OneDrive en el sistema operativo para hacer todo este trabajo de cifrar el contenido y eliminar los archivos originales. ¿Por qué?
Figura 5: Un Ransomware que usa OneDrive para cifrar y borrar archivos
Pues tan sencillo como que el agente de OneDrive en el sistema operativo está en las listas blancas de los EDR ya que su función es copiar, cambiar, borrar, archivos y carpetas del sistema operativo masivamente. Así que todos los EDR lo ponen en listas blancas.
Figura 6: Arquitectura del ataque de DoubleDrive.
Explicación a continuación.
Dicho esto, lo que hay que hacer es conseguir configurar OneDrive para que sincronice todos los archivos que se quieren cifrar en una cuenta de OneDrive en la nube. Es decir, configuramos OneDrive para que sincronice los archivos de local con una copia en OneDrive, y hacer que la copia de OneDrive esté cifrada, y machaque la copia local. Esta es la parte que se parece a nuestro ataque, ya que nosotros ciframos los archivos que ya están en OneDrive y en Office365.
Lo que la diferencia es que el ataque de DoubleDrive busca hacer la sincronización desde local con la nube de los archivos que quiere cifrar, así que es un ataque que se produce en el sistema operativo por un programa malicioso que corre en local.
Figura 8: Se hace login de OneDrive con una cuenta controlada por el atacante
Para ello, plantea varias estrategias para lograr esa sincronización. La primera, y más sencilla, es configurar la cuenta a la que se conecta el agente de OneDrive en local con una cuenta de OneDrive en la nube controlada por el atacante. Se configuran las carpetas a sincronizar, y según el proceso de OneDrive va subiendo los archivos, se cifran en la nube, y el miso agente de OneDrive en local los va machacando, saltándose cualquier EDR en el sistema operativo.
Figura 9: Se roba el token de acceso de la cuenta de OneDrive que se usa en local
La segunda estrategia consiste en conseguir acceso a la cuenta actual del propio OneDrive que está corriendo en local. Para lo que consigue el token de acceso (autorizado previamente), desde el fichero del log de OneDrive, que son los ficheros .odl, que son unos binarios donde el Token de Acceso está ofuscado, pero que con una herramienta escrita en Python, que ha publicado en GitHub, se puede desofuscar y extraer.
También se puede extraer ese Token de Acceso haciendo un volcado de la memoria del proceso de OneDrive, que es bastante sencillo de ejecutar, tal y como ha explicado en las diapositivas de la presentación que ha utilizado.
Figura 11: Robo de tokens con volcado de memoria
Una vez que se tiene el Token de Acceso, para automatizar el proceso del Ransomware, ha publicado la herramienta OneDrive DoubleDrive que utiliza el Token de Acceso, y la lista de ficheros a cifrar, para realizar el proceso de vincular la copia local con la copia en la nube usando OneDrive y hacer el cifrado de los archivos en el almacén en la nube, que será sincronizado después en local.
Al final, esta técnica lo que busca es que los archivos en local queden cifrados como un Ransomware, saltándose las protecciones de los EDR utilizando el agente de OneDrive, mientras que en Ransomcloud, lo que buscamos es cifrar el contenido almacenado en la nube, robando un Token OAuth que nos permita controlar todo el servicio en la nube. Esta estrategia de usar agentes como OneDrive, Dropbox y similares, es muy común en los equipos del Red Team.
Microsoft ha actualizado el agente de OneDrive, para eliminar el almacenamiento de los tokens en los ficheros log, pero el agente necesita seguir utilizando en memoria dicho token. Eso si, realizar un volcado de memoria de un proceso es una acción que los EDR pueden detectar con más facilidad como un comportamiento negativo. Eso sí, me gustaría verlo en acción contra nuestro Latch ARW.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
