Desde GREIN (Grupo de Elaboración de Inteligencia de S2 Grupo) se ha elaborado un informe relacionado con el grupo GAMAREDON. Este grupo según informes previos de PaloAlto y Looking Glass centra su actividad en atacar a Ucrania.

El informe pretende actualizar la información relacionada con este grupo desde un punto de vista técnico y explicar la situación actual que se vive entre dos países como Rusia y Ucrania con un análisis geoestratégico y geopolítico.

Quizá uno de los aspectos más interesantes del estudio y que merece la pena resaltar es este comentario de @DrunkBinary el 30 de Noviembre de 2018:

En este comentario, y en otros referentes a GAMAREDON, @DrunkBinary lanza la hipótesis de que Ucrania puede estar siendo objeto de ataque de unos alumnos pertenecientes a una academia del FSB (vamos como si fuera la academia Enigma del FSB :O) y estos estuvieran haciendo sus prácticas sobre un objetivo real. Después de realizar este informe pensamos que no es una hipótesis muy descabellada, difícil de verificar, pero hay varios indicadores que hacen pensar que esto pudiera ser así.

Aunque fuera cierto que se tratara de una academia atacando, no hay que olvidar que están infectado a víctimas reales por la información manejada por GREIN y por lo publicado recientemente por el CERT de Ucrania, con la gravedad e impacto que esto conlleva.

Desde GREIN esperamos que les sea de utilidad el informe y cualquier comentario será bienvenido.

– Descargar informe –

La entrada Informe: Grupo Gamaredon aparece primero en Security Art Work.

¿Has realizado alguna compra por Internet últimamente? ¿Has accedido a algún servicio digital? ¿Y crees que las decisiones tomadas al comprar o acceder a dichos servicios ha sido una decisión libre y atendiendo a tus propios criterios? Pues va a ser que no…

No dudamos que has buscado, comparado y tomado una decisión propia en base a gustos y necesidades, pero siento decirte que a tus gustos y necesidades le han dado “algo de ritmo”, es decir, tu decisión en gran medida ha sido “algoritmizada” (que es una palabra inventada, lo sé, pero en algún momento había que inventarla…)

Sobre algoritmos y su capacidad o competencia para dirigir nuestras decisiones vitales y no tan vitales se ha escrito largo y tendido y desde multitud enfoques en este y otros muchos blogs. Sin embargo, me gustaría compartir con vosotros mis dudas e inquietudes acerca de una aplicación concreta de los algoritmos. La toma de decisiones en el ámbito penal y el impacto de los sesgos en dichas decisiones.

El profesor Enrique Dans en su artículo Justicia y algoritmos: el estado de California y la libertad bajo fianza nos explica que el citado estado ha aprobado una ley que eliminará el pago de fianza en los tribunales, y recurrirá en su lugar a algoritmos que estimarán el riesgo de fuga o de cometer delitos adicionales en caso de ser puestos en libertad.

Explica el artículo que los defensores de los derechos civiles aplauden la eliminación de la fianza por considerar que es una “práctica discriminatoria que daba lugar a una justicia diferente para ricos y pobres”. Sin embargo, el diseño de los algoritmos contiene sesgos provenientes de los equipos que los desarrollan y los datos que los alimentan, por lo que, asegurar sin ningún género de duda que un algoritmo será neutral por defecto es, cuando menos, arriesgado. Esto no quiere decir que las personas que desarrollan algoritmos en todos los casos y de manera consciente quieran incorporar sesgos a los mismos, sino que mantener un algoritmo “limpio” de sesgos es realmente complicado. En este hilo de twitter, por ejemplo, se comenta inicialmente que el traductor turco-inglés de Google tiene un claro sesgo machista puesto que la traducción de ciertas profesiones, si estas históricamente se han desempeñado por hombres o mujeres, no ofrecen los mismos resultados en su traducción para ambos géneros (ingenierO; enfermerA). La explicación ofrecida es la frecuencia de uso, es decir, si en la base de datos que alimenta el algoritmo aparecen 900 ingenieros y 100 ingenieras el algoritmo ofrecerá como resultado principal el más usado. En ese punto se acusa a los desarrolladores de haber sido descuidados y “vagos” por no haber considerado incorporar factores de corrección para contrarrestar los sesgos provenientes de los datos que alimentan el algoritmo. También se plantea la necesidad de distinguir entre el algoritmo propiamente dicho y los datos que lo alimentan. Visto lo anterior, ¿hasta qué punto podemos considerar que la incorporación de un sesgo a un algoritmo es algo consciente, o derivado de falta de buenas prácticas?

Aunque la citada normativa aprobada hace foco en las medidas cautelares antes de un juicio (ingreso en prisión sin fianza u opcionalmente pago de fianza) debemos considerar que pasaría si el uso de algoritmos se extendiera a la determinación de las penas derivadas de una sentencia. Tomando algunas notas del trabajo “Individualización de la pena” indico a continuación las que, a priori, parecen complicadas de aplicar de manera neutral u objetiva:

• Determinación de Penas “Elásticas”: la ley determina un máximo y un mínimo, el juez debe fijarla según la naturaleza del hecho y a la personalidad del delincuente:
• Individualización judicial: Es la que hace el juez con arreglo a las modalidades objetivas y subjetivas del delito cometido. Deben considerar:
  • la educación, las costumbres y la conducta precedente del sujeto,
  • la calidad de los motivos que lo determinaron a delinquir,
  • los demás antecedentes y condiciones personales,
  • los vínculos sociales, la calidad de las personas y las circunstancias que demuestren su mayor o menor peligrosidad.
  • estado de salud, su sexo, su inteligencia, su posición profesional y social.
• el juez debe tomar conocimiento directo y personal del sujeto.

La dificultad no está tan sólo en aplicar estas características a un algoritmo o una base de datos, sino hacerlo de manera neutral, sin que los sesgos y prejuicios que están arraigados en nuestra sociedad se trasladen al resultado.

El artículo del profesor Dans indica otros puntos que pueden ser controvertidos desde el punto de vista de la neutralidad y del viejo (y maltratado) principio de la “ley es igual para todos”:

• “El algoritmo, que los diferentes condados tendrán obligación de obtener bien a través de algún proveedor o mediante desarrollo propio”. ¿Cómo se garantizará la unificación de criterios de desarrollo o que los datos de alimentación serán consistentes?
• “Un algoritmo (..) para estimar el riesgo de reincidencia de los convictos y ayudar a los jueces a tomar decisiones sobre la extensión de sus penas (…) fue objeto de apelación (…), el acusado alegó que el uso de dicho algoritmo (..) violaba sus derechos porque evitaba que impugnase la validez científica (..) al desconocer el funcionamiento del algoritmo, y porque éste tenía además en cuenta variables como el género y la raza del acusado”. Las empresas desarrolladoras se escudan en principios de propiedad intelectual para no revelar los detalles sobre sus algoritmos. Siendo un punto de vista respetable y comprensible es evidente que impacta en el derecho de defensa al desconocer los motivos (variables) del resultado, chocando además con la obligación de dictar sentencias “motivadas” y “argumentadas”. En algunos casos, incluso los propios desarrolladores reconocen que ni siquiera ellos son capaces de explicar los resultados obtenidos de un modelo, puesto no son capaces de desentrañar qué camino ha seguido el modelo para llegar a una determinada conclusión.

Debemos considerar, además, otros aspectos a la hora de cuestionar la neutralidad de los algoritmos. Por ejemplo, los cambios normativos o la jurisprudencia y su impacto en las sentencias posteriores, ¿con que agilidad pueden aplicarse e implantarse?
Las soluciones no parecen sencillas pero al menos ambos mundos (tecnológico y jurídico) han tomado conciencia del mismo y, cada uno con su enfoque y a su “ritmo”, han empezado a pensar y aplicar diferentes soluciones.

• Consensuar principios para hacer un uso responsable de la inteligencia artificial y Elaboración de Códigos Éticos.
• Creación de proyectos, herramientas, y retos para detectar sesgos:
  • Telefónica está organizando un reto en el área de LUCA, su unidad de datos.
  • Accenture: ha desarrollado AI Fairness
  • IBM: Trust and Transparency in AI
• Protección de Datos: Privacidad desde el diseño identificando las finalidades del algoritmo e informando de la inclusión de los datos en bases de datos que alimentarán algoritmos y, previsiblemente, podrán crear perfiles en base a los mismos.

Desde el punto de vista de Auditoría/Consultoría/Seguridad habrá que atender a los dos aspectos clave de la problemática, el algoritmo y la base de datos que alimenta:

• Algoritmo: CCN-STIC-807.
• Base de datos:
  • General: Metodología
  • Aplicación de técnicas específicas para reducir sesgos:
    • Reordenación de resultados en pequeños subgrupos y verificación de proporciones de datos en cada uno de ellos.
    • Eliminar el “impacto dispar”, analizando los resultados dispares y aplicando factores de corrección en los resultados “sesgados”
    • Introducir restricciones proequidad a todos aquellos resultados cuando la ratio sea menor a un 80% (es el límite establecido para considerar que los resultados son discriminatorios).

En conclusión, está claro que los algoritmos impactarán en la rapidez de toma de decisiones, pero debemos estar atentos para garantizar que la rapidez no disminuirá la neutralidad ni la igualdad en los resultados. Si aplicamos “algo de ritmo”, que no perdamos el paso…

La entrada “ALGO” de “RITMO”: algoritmos en la toma de decisiones aparece primero en Security Art Work.

El artículo de hoy es cortesía de John Mason, cofundador de TheBestVPN.com y articulista en Tripwire, StaySafeOnline, DigitalGuardian y Educause. Puedes encontrarlo en twitter como @JohnCyberMason.

¿Confías en tu router para mantenerte a salvo de hackers y espías? Puede que quieras echar otro vistazo sólo para asegurarte.

Akamai descubrió recientemente una campaña de malware que ya ha comprometido a más de 45 113 routers domésticos y corporativos. Para ello se utilizó una herramienta basada en las herramientas de hacking de la NSA que se filtraron en 2017. Para explicar cómo los hackers utilizan esta herramienta para convertir un router en un servidor proxy, primero tenemos que entender cómo funciona UPnP.

UPnP es un protocolo que facilita la detección de dispositivos y servicios, así como la configuración de dispositivos y redes de consumo. Su propósito principal era permitir que los dispositivos de una LAN expusieran automáticamente los servicios y la funcionalidad a otros dispositivos de la red local.

Un papel importante que desempeña es el de negociar y configurar automáticamente la apertura/envío de puertos dentro de un entorno de red “nateado”, lo que permite a los dispositivos de red abrir puertos y acelerar el enrutamiento del tráfico de red. Esta característica a menudo se implementa de forma predeterminada en los routers domésticos para mejorar el rendimiento y la experiencia del usuario cuando se juega en red.

El problema con UPnP es que algunas de sus implementaciones no manejaban segmentación de red a través de las interfaces de red WAN y LAN correctamente. En DEFCON 19, se presentó un conjunto de herramientas que permitía a los usuarios remotos inyectar reglas NAT en un dispositivo remoto a través de la interfaz WAN.

En 2013, Rapid 7 descubrió 80 millones de dispositivos vulnerables. Utilizaron la información filtrada por los dispositivos para identificar proveedores, modelos y el panorama general de amenazas. Esto les llevó a identificar miles de modelos de más de 1500 proveedores.

Entonces, ¿cómo funciona la inyección NAT?

Normalmente, los servicios privilegiados sólo pueden ser utilizados por dispositivos de confianza en una LAN. Sin embargo, los dispositivos vulnerables exponen estos servicios privilegiados en su interfaz WAN. Un atacante puede entonces utilizar estos servicios expuestos:

• Para inyectar entradas NAT en el dispositivo remoto.
• Para exponer máquinas detrás del enrutador.
• Para inyectar hosts enrutables por Internet en la tabla NAT (lo que hace que el enrutador actúe como un servidor proxy).

En abril de este año, Akamai publicó un white paper detallando el proceso de cómo los hackers utilizan UPnP para convertir los routers en servidores proxy. Pero, recientemente descubrieron que los hackers tienen un nuevo método para instalar reglas especiales en las tablas NAT, que son las que deciden cómo se envía el tráfico desde el router a los dispositivos de la red. Estos hackers añaden una entrada a la tabla NAT llamada “Galleta Silenciosa“.

Las reglas siguen funcionando como redirecciones proxy, pero en lugar de simplemente retransmitir el tráfico web, ahora también permiten a los hackers conectarse a los puertos SMB (139, 445) de los dispositivos y equipos dentro de la red del router.

Akamai no pudo identificar exactamente el mecanismo, pero tienen serias sospechas de que las “inyecciones” están vinculadas a EternalBlue, una herramienta de hacking (malware) desarrollada por la NSA, que también se utilizó para las epidemias de WannaCry y NotPetya.

Esto es lo que llevó a Akamai a apodar esta campaña de hacking “EternalSilence”, a partir de EternalBlue y Silent Cookie — las entradas maliciosas en la tabla NAT.

La cuestión es que identificar si uno está afectado no es tarea fácil, aunque hay algunos pasos que se pueden seguir si sospechas que tu router es vulnerable a la infección NAT.

Si te conectas regularmente a Wi-Fi públicas, asegúrate de utilizar un servicio VPN para minimizar el riesgo, ya que esa red pública puede estar utilizando un router vulnerable.

Según el informe de Akamai, hay una forma de escanear el endpoint y auditar las entradas de su tabla NAT, pero esto implica un conocimiento técnico avanzado.

Podrías flashear tu router y deshabilitar UPnP, pero Akamai dice que esto sólo servirá para mitigar el problema, por lo que la mejor solución sugerida es simplemente reemplazar tu router vulnerable si encuentras su marca en la lista proporcionada en el informe.

La entrada EternalSilence: por qué tu router puede estar en riesgo a causa de esta herramienta de la NSA aparece primero en Security Art Work.

A finales del pasado mes de diciembre, Microsoft publicó un documento titulado What’s new in Windows Server 2019 sobre las nuevas características y funcionalidades renovadas que aportará esta nueva versión de Windows Server. Esta entrada, como no podría ser de otra manera, se centrará en aquellas funcionalidades relacionadas con las mejoras en seguridad que aporta Windows Defender ATP y que ya se habían visto en Windows 10 a través de Windows Defender Exploit Guard, EMET (Enhanced Mitigation Experience Toolkit) que dejó de tener soporte el pasado 31 de julio de 2018, así como WDAC (Windows Defender Application Control).

Conforme se estaba desarrollando la entrada, se fue ahondando en la investigación y esto llevó a un documento mucho más completo sobre ATP, en concreto Windows Defender Advanced Threat Protection. Este post pretende ser un breve resumen ordenado de todo aquello que recogen los múltiples enlaces del documento anteriormente citado.

Protección contra Amenazas Avanzadas de Windows Defender (Windows Defender Advanced Threat Protection, ATP)

El sistema ATP de Windows Defender está diseñado para proteger el kernel y la memoria del sistema frente a ficheros y procesos maliciosos, ya sea a través del bloqueo o mediante la finalización de éstos, con el objeto de prevenir la intrusión en el host. En su desarrollo, se apoya en varios aspectos a tener en cuenta para reducir la intrusión.

Reducción de la Superficie de Ataque (Attack Surface Reduction, ASR)

La reducción de la superficie de ataque (ASR) se fundamenta en un conjunto de reglas complejas gestionadas por los administradores del sistema que permiten bloquear archivos potencialmente peligrosos en función de su comportamiento. Estas reglas realizan el bloqueo de estos ficheros basándose, principalmente, en los siguientes aspectos o comportamientos:

• ejecutables en el correo.
• procesos secundarios, llamadas a API de Win32 desde macros o ejecutables creados por aplicaciones de Office, así como la posibilidad de inyección de código por esta.
• scripts que ejecuten código descargado por ellos, procesos sin firmar y no confiables desde USB, …

Protección de Red (Network Protection)

Esta capacidad de filtrado de red se encuentra en el kernel del sistema y está orientada a proteger el host. En este caso, bloquea aquellas conexiones salientes del equipo contra dominios potencialmente peligrosos para evitar daños producidos por phishing, sitios que pueden intentar instalar malware en la máquina e incluso propagarse por el resto de máquinas de la red. El bloqueo se fundamenta, principalmente, en inteligencia de reputación basada tanto en la IP como en el nombre del dominio, combinando búsquedas online y almacenamiento en caché, por lo que si el resultado indica que la conexión se dirige a un sitio de mala reputación se bloquee la salida a Internet para dicho malware basado en web, tanto si la llamada se genera desde un navegador o desde un proceso en segundo plano.

Carpetas de Acceso Controlado (Controlled Access Folder)

En los últimos años, han sido muy notorios los ataques por ransomware que han provocado el cifrado de archivos en organizaciones y empresas. Para evitar estos comportamientos, se dispone del acceso controlado a carpetas. En esencia, lo que se pretende es evitar el uso de ficheros por parte de procesos que no se hayan definido como procesos de confianza. La gestión de esta característica en la infraestructura TI se podrá llevar a través de GPO o PowerShell. Además de definir los controles, cada vez que se bloquee un intento de llevar a cabo un cambio en directorios protegidos, se generará una alerta en Windows Defender ATP.

Protección contra Vulnerabilidades (Exploit Protection)

La protección contra vulnerabilidades ya estaba presente en EMET y ahora se dispone de ella en Windows Defender ATP. Dado que EMET ha dejado de tener soporte, Microsoft ha implementado mecanismos para la migración de las reglas definidas en EMET a ATP. Entre las mitigaciones que lleva a cabo están las relacionadas con la ejecución de código, la validación de integridad de imágenes remotas, el bloqueo de fuentes que no sean de confianza, validaciones al API, bloqueo de procesos secundarios, validación de controladores. Como se ha comentado algunas ya estaban presentes en EMET y otras son propias o han sido mejoradas por ATP.

Respecto a los cuatro puntos citados hasta el momento, todos estos mecanismos se pueden habilitar en modo auditoría de manera que se pueda ver el comportamiento del sistema simulando su aplicación, dejando traza de las acciones simuladas en los registros de eventos, de manera que tras un período de tiempo definido para el análisis, se pueda determinar si las reglas diseñadas son válidas y pueden pasar a producción. Además, el administrador podrá habilitar la notificación de forma que el usuario sea consciente de los bloqueos. Esto es útil en caso de que pudiera producirse un falso positivo y el usuario pueda notificar del error provocado por el mecanismo de bloqueo.

Control de Aplicaciones de Windows Defender (Windows Defender Application Control, WDAC)

Como se indica en el artículo, el WDAC apareció con Windows Server 2016. Como mejora de la gestión, Microsoft ha desarrollado directivas de Integridad de Código (CI), de manera que se pueda bloquear aquellos ejecutables que pongan en riesgo la integridad. En este caso, en lugar de ver todas las aplicaciones o librerías como confiables, se revierte el planteamiento y se presupone la no confianza, por lo que explícitamente se deberán establecer qué aplicaciones pueden ejecutar los usuarios y qué código podrá ejecutarse en el kernel del sistema. Por otro lado, también se incorpora la capacidad de bloqueo de scripts y .msi sin firmar, así como determinar si se pueden ejecutar complementos o módulos de aplicaciones a través de sencillas reglas que relacionan ejecutables con librerías.

Aislamiento basado en hardware (Hardware-based isolation)

• Aislamiento de aplicaciones
  Este modelo se basa en la definición de todos aquellos sitios que la organización considera que son de confianza. Por tanto, el acceso a sitios que no estén recogidos se considerarán de no confianza. Cuando se accede a un sitio de no confianza, el acceso se realiza en un contenedor aislado, por lo que si el sitio es realmente malintencionado, el host estará protegido frente a la intrusión, ya que dicho contenedor es anónimo y, por tanto, no tiene acceso a la obtención de credenciales de usuario.
• Aislamiento del sistema
  Proteger y mantener la integridad del sistema en el inicio.
  El sistema está preparado para evitar que ningún bootkit se inicie antes que el cargador de arranque del sistema operativo. Para ello, se hace uso de hardware basado en Root of Trust (RoT), que es un elemento de la Unified Extensible Firmware Interface (UEFI). Tras esta validación se puede iniciar el arranque de Windows y el firmware.

  Proteger y mantener la integridad del sistema tras el arranque.
  A pesar de las dificultades que se han desarrollado para evitar mecanismos de aumento de privilegios, todavía no se está seguro de poder mantener la integridad de los servicios críticos del sistema operativo. Para ello, a partir de Windows 10, apareció el modelo de seguridad basado en virtualización (VBS). Con este concepto, se permite aislar los datos en modelo basado en hardware. De esta forma se permite, en tiempo de ejecución, proteger servicios críticos como Credential Guard, Device Guard, TPM Virtual y partes de Windows Defender, etc.

  Validación de la integridad del sistema de forma local y remota.
  A través de Trusted Platform Module 2.0 (TPM 2.0), el sistema obtiene datos que servirán como medidas de integridad. Tanto el proceso como la información se aíslan del hardware, para que la obtención de datos no esté sujeta a alteraciones. A través de sistemas remotos como Intune o System Center Configuration Manager (SCCM) se pueden solicitar para el análisis. Si el análisis indica que el sistema está comprometido, se podría, por ejemplo, denegar el acceso a los recursos ofrecidos por el dispositivo comprometido.

Como se ha comentado, lo que se ha pretendido con la entrada es realizar una primera aproximación a Windows Defender ATP, ofreciendo un resumen de las opciones a investigar por parte de los administradores de sistemas, con el objeto de potenciar al máximo los niveles de seguridad que se ofrece en Windows Server 2019.

Bibliografía y Recursos

• What’s new in Windows Server 2019
• Windows Defender Advanced Threat Protection
• Windows Defender ATP (zona demo)

La entrada Seguridad en Windows Server 2019 aparece primero en Security Art Work.

Después de más de 7 meses de la entrada en vigor de la aplicación del RGPD, la mayoría de las Administraciones Públicas y muchas de las empresas privadas que trabajan para ellas en procesos críticos, como vigilancia de la red, seguridad perimetral, mantenimiento y soporte de sistemas, desarrollo y/o mantenimiento de aplicaciones, se enfrentan actualmente al reto de integrar su adaptación al RGPD con su declaración o certificación de conformidad con el Esquema Nacional de Seguridad, ENS.

El RGPD y el ENS exigen demostrar conformidad y comparten requisitos regulatorios basados en la exigencia de realizar un análisis de riesgos y en implantar medidas enfocadas a mitigar los riesgos identificados.

Dado que el RGPD no establece medidas técnicas para tratar los riesgos en privacidad, sino que las deja sujetas a la responsabilidad proactiva de cada responsable o encargado de tratamiento, para muchos responsables de tratamiento esta definición de medidas puede no ser trivial. Esto está ocurriendo en algunas empresas a pesar de disponer de medidas establecidas por estándares de seguridad como puede ser la ISO 27001. En cambio, para otras empresas y sus clientes en la Administración Pública parece tarea más sencilla, ya que la nueva Ley Orgánica de Protección de datos Personales y garantía de los derechos digitales ya aprobada y publicada en el BOE el 6 de diciembre, regula en su Disposición adicional primera (“Medidas de seguridad en el ámbito del sector público”) que el Esquema Nacional de Seguridad incluirá las medidas que deban implantarse en caso de tratamiento de datos personales y que las AAPP deberán aplicar a los tratamientos dichas medidas, así como impulsar un grado de implementación de medidas equivalentes en las empresas que les presten servicios.

Sin embargo, la realidad es que tampoco es tan fácil ya que adicionalmente a las medidas del ENS también hay que aplicar las medidas de seguridad necesarias derivadas del análisis de riesgos. Dado que el ENS no regula, entre otras cosas, lo que hay que hacer con el tan temido papel que sabemos que aún abunda en las AAPP, las medidas a aplicar por el ENS pueden no abarcar todos los medios que se utilizan para los tratamientos de datos personales realizados.

Por su parte, la nueva Ley Orgánica tiene además otras exigencias adicionales para las AAPP, como la publicación de un inventario de sus actividades de tratamiento accesible por medios electrónicos en el que constará la información establecida en el artículo 30 del Reglamento (UE) 2016/679 y su base legal (art. 31).

Además, el artículo 8.2 establece que el tratamiento de datos personales “solo podrá considerarse fundado en el cumplimiento de una misión realizada en interés público o en ejercicio de poderes públicos conferidos al responsable, en los términos previstos en el artículo 6.1 e) del RGPD, cuando derive de una competencia atribuida por una norma o rango de ley (art. 8)“. Es por ello, que en el registro de actividades de tratamiento se debe reflejar, no sólo la base legal sino también la ley que aplique.

Por si todo lo anterior fuera poco, en el añadido Título X dedicado a la garantía de los derechos digitales, se encuentra el artículo 87, que regula el Derecho a la intimidad y al uso de dispositivos en el ámbito digital. Destacar que los trabajadores y los empleados públicos tendrán derecho a la protección de su intimidad en el uso de los dispositivos digitales puestos a su disposición por su empleador, que éste podrá acceder a los contenidos derivados del uso de medios digitales facilitados a los trabajadores a los solos efectos de controlar el cumplimiento de las obligaciones laborales o estatutarias y de garantizar la integridad de dichos dispositivos y establecer criterios de utilización de los dispositivos digitales respetando en todo caso los estándares mínimos de protección de su intimidad de acuerdo con los usos sociales y los derechos reconocidos constitucional y legalmente, en cuya elaboración deberán participar los representantes de los trabajadores.

El acceso por el empleador al contenido de dispositivos digitales respecto de los que haya admitido su uso con fines privados requerirá que se especifiquen de modo preciso los usos autorizados y se establezcan garantías para preservar la intimidad de los trabajadores, tales como, en su caso, la determinación de los períodos en que los dispositivos podrán utilizarse para fines privados.

Esta disposición también dificulta la aplicación de las medidas del ENS, dado que se antoja difícil establecer medidas técnicas que garanticen la integridad de los dispositivos digitales y al mismo tiempo respeten los estándares mínimos de protección de la intimidad de los individuos, ya que el límite entre el uso privado y con fines laborales puede ser muy difuso, si no hay establecidas normativas concretas al respecto o si las normas existentes dejan cierto margen de flexibilidad.

Pero hay una buena noticia, y es que el Centro Criptológico Nacional junto con la Agencia Española de Protección de Datos, está elaborando la Guía CCN-STIC 881 Impacto del RGPD en el ENS, que será publicada en breves fechas, cuyo objetivo es establecer un Modelo de Evaluación Combinado que facilite a las entidades del Sector Público la aplicación simultánea de ambas regulaciones, los requisitos de evaluación, y que permita la obtención de las adecuadas exigencias de conformidad.

Esperamos que también sirva de ayuda a las empresas privadas que por exigencia en los pliegos de contratación o simplemente por ventaja competitiva, tengan que seguir el mismo camino.

La entrada El reto de integrar RGPD, ENS y ahora también LOPD-GDD aparece primero en Security Art Work.

El eterno juego del ratón y el gato entre atacantes y defensores en el mundo de la ciberseguridad ha implicado históricamente una mejora constante de las metodologías llevadas a cabo por ambas partes. El rápido y novedoso desarrollo de la Inteligencia Artificial (IA) resulta muy atractivo para el desarrollo de nuevas metodologías tanto para los atacantes como para los defensores.

A grandes rasgos, la IA hace referencia al aprendizaje que pueden realizar las máquinas u ordenadores en este caso, para llevar a cabo acciones consideradas como “inteligentes”. Uno de los grandes retos de esta disciplina consiste en dotar de capacidades “humanas” a éstas para que puedan llegar a tener comportamientos semejantes a los nuestros. Una de las ramas con mayor potencial hoy en día en la inteligencia artificial es la denominada ‘Machine Learning’. El objetivo básico de esta rama consiste en “entrenar” a la máquina para que sea capaz de dar una respuesta adecuada en base a unos parámetros de entrada.

MACHINE LEARNING

Dentro de esta rama se encuentran dos tipos de técnicas: aprendizaje supervisado y no supervisado. El aprendizaje supervisado se encarga de entrenar un tipo de modelo basado en inputs y outputs conocidos, con la finalidad de poder predecir futuros outputs. Por su parte, el aprendizaje no supervisado se encarga de estimar patrones a partir de unos determinados inputs.

Otro concepto a tener en cuenta es el de redes neuronales. Este modelo de datos, empleado tanto en las técnicas de entrenamiento supervisado como en no supervisado, trata de emular el funcionamiento del cerebro humano. Normalmente se organizan en tres partes: la primera es la capa de entrada o inputs, la segunda se constituye de varias capas intermedias, y la tercera es la capa de salida, con una o varias unidades de destino. La peculiaridad de esta técnica reside en que cada ‘neurona’ dispone de una ponderación variable que va entrenándose y mejorándose hasta que consigue una precisión elevada.

Cabe también mencionar en este informe una de las técnicas más recientes en la IA. Esta técnica denominada ‘GAN’ (Redes Generativas Adversarias o Generative Adversarial Networks por sus siglas en inglés), consiste en emplear dos redes neuronales, una para que trate de crear lo que se supone que debe crear (por ejemplo: imágenes de caras humanas), y la otra red neuronal para discriminar (por ejemplo: determinar si una imagen corresponde a un rostro humano o no). Con el paso del tiempo, ambas redes neuronales van probándose la una a la otra y mejorando hasta que a la red discriminadora le resulta imposible determinar si la imagen que está visualizando es real o no. Gracias a esta técnica, se han conseguido crear, entre otras cosas, imágenes y sonidos hiperrealistas.

CIBERSEGURIDAD

Cada vez más son las empresas en el sector de la ciberseguridad que están empleando ‘Machine Learning’ para detectar posibles amenazas, basando su entrenamiento en el histórico de amenazas resueltas por parte de los analistas. De esta forma y dada la cantidad tan elevada de amenazas resueltas que pueden estar registradas en una empresa del sector, el entrenamiento llevado a cabo por parte de la IA puede ser muy efectivo y muy útil.

Por poner un ejemplo que refuerce el potencial que tiene el uso de ‘Machine Learning’, supongamos que en el sector de ciberseguridad se disponen de servidores llenos de Terabytes de información que podrían contener, por ejemplo, todos los historiales de todos los eventos maliciosos que han sido detectados. Dada la tendencia creciente de ataques, es lógico pensar que un analista puede llegar a verse desbordado. Es aquí donde la IA basada en ‘Machine Learning’ hace su aparición.

Esta rama de la IA, mediante alguno de sus campos de aplicación, podría ser capaz de aprender de los historiales de eventos maliciosos mediante un entrenamiento previo, escogiendo como parámetros de entrada los factores más importantes que le han llevado al analista a catalogar ese evento como malicioso (p.e tamaño del archivo, contenido del archivo, dirección IP origen, comportamiento, tipo de conexión…). Gracias a este entrenamiento, nuestra IA entrenada mediante ‘Machine Learning’ podría ser capaz de determinar con una alta precisión, la probabilidad de que un evento sea malicioso o no.

Además, desde el punto de vista de la ciberseguridad, sería interesante adentrarse por una parte en el mundo de las redes neuronales para que nuestra IA pueda aprender de nuevos patrones no conocidos, y por otra parte, se debería profundizar en la técnica ‘GAN’ mencionada anteriormente para entrenar a nuestra red neuronal con casos reales de eventos maliciosos y así conseguir determinar de una forma mucho más eficaz las posibles amenazas.

AMENAZAS

Al igual que la IA está suponiendo una ventaja para los defensores de la ciberseguridad, parece ser que también empiezan a surgir distintas propuestas de ataque llevadas a cabo mediante la combinación esta disciplina junto con las metodologías clásicas existentes.

Hoy en día no existen registros definidos de su uso ya que este es muy incipiente y muy limitado. No obstante, si que disponemos de investigaciones hechas por empresas y universidades que alertan de su probable uso inmediato por parte de los cibercriminales.

• Malware evasivo: Investigadores de IBM han creado un tipo de malware evasivo denominado ‘DeepLocker’, que emplea inteligencia artificial para mantener su payload malicioso oculto (por ejemplo en un software de videoconferencias), a la espera de encontrar una víctima concreta mediante reconocimiento facial. El empleo de esta técnica hace que su desbloqueo mediante ingeniería inversa sea prácticamente imposible hoy en día. El caso de aplicación que emplea esta IA es el modelo de ‘Redes Neuronales Profundas’ o DNN (Deep Neural Network).
• En contra de la propia IA: Los cibercriminales podrían hacer uso de los conocimientos que pueda tener un sistema de IA entrenado en un entorno concreto para tratar de engañarlo. Por poner un ejemplo, en el caso de que se emplee la IA en el sector de la ciberseguridad para detectar nuevas amenazas, si el cibercriminal llega a ser capaz de conocer el modus operandi acerca de cómo ésta determina una potencial amenaza, podría camuflar su ataque mediante técnicas que la IA no considera como amenazas para así poder pasar desapercibido.Una buena contramedida a esta técnica es evitar que personal no autorizado acceda al modelo de entrenamiento de la IA entrenada y por supuesto, nunca confiarle de forma absoluta a la IA la tarea de determinar si los distintos eventos suponen una amenaza o no. La IA tiene que establecerse como una base de apoyo al analista y en ningún caso debería suplir a este.
• Suplantación de identidad e ingeniería social: Uno de los ámbitos en los que más está avanzando la IA mediante el uso de ‘Redes Neuronales Profundas’ es en la recreación de características humanas. Por ejemplo nos encontramos que la IA es ya casi capaz de recrear el habla con voz humana. Imaginemos que podría ocurrir si el acceso a un lugar se realiza mediante control de voz o incluso si realizamos una llamada a la empresa con la voz de algún responsable de área o incluso del jefe, en el cual confiamos plenamente.Las ‘Redes Neuronales Profundas’ pueden también emplearse para saltarse los controles biométricos mediante huella dactilar, tal y como han desarrollado expertos de la Escuela de Ingeniería de la Universidad de Nueva York en lo que ellos han denominado ‘DeepMasterPrints’. Esta herramienta aprovecha que existen zonas de las huellas que tienen muchas características comunes (https://arxiv.org/pdf/1705.07386.pdf) y que la mayoría de escáneres no leen la huella dactilar completa, lo que permite facilitar la labor de los cibercriminales. Además, para lograr un mayor porcentaje de éxito, los investigadores han creado huellas realistas entrenando la IA con huellas dactilares reales mediante una ‘GAN’.

En definitiva, podemos concluir que el rápido desarrollo de la IA, sumado a su alto potencial, puede cambiar la forma en la que entendemos la ciberseguridad. Además, debido a que gran parte de esta tecnología se encuentra de forma pública en Internet y su integración con las diferentes técnicas de ataque son viables tal y como hemos estudiado anteriormente, se puede estimar que va a existir una inevitable tendencia al alza de su uso por parte de los ciberdelincuentes. Por su parte, el sector de la ciberseguridad deberá adaptarse empleando IA a corto/ medio plazo para no encontrarse indefenso ante los ciberdelincuentes que empleen esta tecnología.

Para acabar, hay una cosa que parece clara, y es que el bando que antes consiga adaptarse a la disciplina de la IA tomará ventaja en la ya histórica carrera.

La entrada Inteligencia artificial y ciberseguridad aparece primero en Security Art Work.

Desde el Grupo de Elaboración de Inteligencia (GREIN) de S2 Grupo se ha llevado a cabo una investigación sobre un actor sobre el que desde GREIN no se han podido encontrar referencias o similitudes en fuentes abiertas y al que se ha identificado como WIRTE.

El equipo de DFIR (Digital Forensics and Incident Response) de S2 Grupo identificó por primera vez este actor en agosto de 2018 y a partir de ese instante se ha llevado a cabo el seguimiento durante los últimos meses.

Este grupo ataca a Oriente Medio y no utiliza mecanismos muy sofisticados, al menos en la campaña iniciada en agosto de 2018 que fue la monitorizada. Se considera poco sofisticado por el hecho de que los scripts están sin ofuscar, las comunicaciones van sin cifrar por HTTP, utilizan Powershell (cada vez más monitorizado), etcétera. Pese a este modus operandi aparentemente poco sofisticado respecto a otros actores, consiguen infectar a sus víctimas y llevar a cabo sus objetivos. Además, como se verá durante este artículo, la tasa de detección de alguno de los scripts en el mes de diciembre de 2018 por los principales fabricantes de antivirus es baja, aspecto que es necesario resaltar. Hay que ser consciente que una vez se ejecutan estos scripts es cuando el análisis por comportamiento de muchas soluciones los detectarán, pero este hecho no ha sido objeto de estudio por parte de GREIN.

Este actor en todos los artefactos analizados muestra a sus víctimas un documento señuelo en árabe con diferentes temáticas. Durante el informe se analizarán estos documentos y quienes podrían ser los objetivos dependiendo de la temática tratada en el documento.

Análisis técnico

Como se ha indicado, durante el mes de agosto de 2018 desde S2 Grupo CERT gestionamos un incidente que tenía como objetivo la diplomacia de diferentes países de Oriente Medio.

Los atacantes utilizaron como herramienta para el control de la víctima un malware realizado en Visual Basic Script (VBS). Partiendo del estudio de este VBS desde S2 Grupo CERT se inició la monitorización de este grupo, encontrando en otras fuentes otros artefactos del mismo grupo pero con diferentes documentos señuelo y con diferentes estrategias de ejecución, persistencia, etcétera. Desde S2 Grupo no se posee suficiente información como para realizar ningún tipo de atribución ni autoría. Se asocia que estos artefactos están relacionados porque reflejan similitudes desde un punto de vista técnico, temporal y por los documentos señuelos utilizados, ya que en ocasiones son idénticos.

Un aspecto observado durante la investigación es que los atacantes después de ejecutar el VBS utilizaban como framework de post-explotación Empire (https://github.com/EmpireProject/Empire).

En total se han podido recopilar cinco scripts más el implicado en el incidente. A continuación detallamos de cada uno de ellos sus características principales.

Script 1: 617bbc71e5f0a645cbb8eeb6d4a1ece96ba0860c8ab5deda6a795e6ad244607a

Este primer fichero se puede ver en Virus Total y posee una detección baja (4/58); el último análisis ha tenido lugar el 12/12/2018.

En este caso el fichero ha sido subido desde Palestina a Virus Total:

En la imagen se puede ver que se ha subido a través de la web, desde PS (Palestina) y además que ha sido subido por primera vez el 05/08/2018.

La comunicación de red se produce por HTTP al dominio micorsoft[.]store al puerto TCP/2082. Este dominio desde que existe ha resuelto a las siguientes direcciones ip:

• 104.31.78.17
• 104.31.79.17
• 185.86.79.243

Actualmente resuelve a una dirección de Cloudflare. El puerto 2082 es uno de los puertos permitidos por Cloudflare para el tráfico HTTP. Cabe destacar que la primera dirección IP 185.86.79.243 está geolocalizada en Ucrania. Esta dirección IP ha sido asignada a diferentes dominios, entre ellos el malicioso.

Aparentemente los atacantes han cambiado de dirección IP y se han ocultado en determinado momento detrás de Cloudflare.

En este script esta información de la comunicación se encuentra toda en la función RunPld(). Esta función tiene como objetivo descargarse código powershell del servidor de mando y control y ejecutarlo:

Otra función común en estos scripts es la función writeDOC. Esta función se encarga de decodificar el documento señuelo (decoy), escribirlo a disco y mostrárselo a la víctima. Este documento está codificado en base64 y embebido en el propio script en una variable.

El script VBS se copia a sí mismo a APPDATA a través de la función copyVBS():

El script por sí solo no establece persistencia en su primera ejecución por lo que o los atacantes la despliegan después cuando ejecutan powershell o la fijan mediante el transporte de este script. El script una vez copiado a APPDATA tendrá el siguiente nombre: Update.vbs.

Por otro lado, si el script se está ejecutando desde APPDATA no muestra el documento y solo ejecuta la función RunPld() que es el backdoor en powershell y que se ha detallado con anterioridad. Si no está siendo ejecutado desde APPDATA muestra el fichero DOC “decoy”, se copia y ejecuta el backdoor (script en powershell).

Cuando la víctima ejecuta el fichero VBS se le abrirá un documento Word con el siguiente contenido (se puede ver a la izquierda en árabe y a su lado la traducción realizada por Google Translate):

El documento que hemos mostrado pretende simular que ha sido enviado desde el Ministerio de Asuntos Exteriores de Arabia Saudita. Presuntamente, parece que el destinatario era el Ministerio de Awqaf y de Asuntos Islámicos de Kuwait, ya que en la misma firma del documento aparece (Kuwait – Jeddah). También estaba dirigido aparentemente al Consulado de Kuwait del Consejo de Cooperación de los Estados Árabes del Golfo, organismo altamente importante dentro de los países del Golfo Arábigo.

El texto menciona que adjunto, el receptor encontrará un documento del Ministerio de Exteriores de Arabia Saudita llamado “asuntos del Hajj”, el cuál es de interés para todos aquellos países árabes que disponen de ciudadanos que mantienen intereses en llevar a cabo la peregrinación a la Meca. Además, incentiva a los receptores a reenviar el documento a otras organizaciones gubernamentales de países con intereses vinculados con el “Hajj” y que hayan sido aprobados por el mismo Ministerio de Cultura de Arabia Saudita. Presuntamente, el autor pretende generar una infección entre los “partner states” de Arabia Saudita; el “target” del emisor podrían ser los miembros del cuerpo diplomático de países con interés en el “Hajj” y sobre todo los diplomáticos que forman parte del Consejo de Cooperación de los Estados Árabes del Golfo, ya que el emisor promueve el reenvío del documento a todas las partes interesadas.

Existen cinco pilares fundamentales dentro de la religión del islam. Uno de ellos es el “Hajj”, el cual implica que todos los musulmanes deben visitar al menos una vez en la vida la Meca. Este monumento está ubicado en la región de Jeddah dentro de Arabia Saudí. El “Hajj” es significativamente relevante para los musulmanes de todo el mundo. Consecuentemente, este texto es atractivo y genera interés tanto a los musulmanes chiitas como a los sunitas.

La fecha de la emisión del documento es relevante ya que se llevó a cabo en agosto, aproximadamente dos semanas antes de la gran peregrinación, justamente cuando miles de personas de fe musulmana iniciarían el peregrinaje hacia Jeddah en Arabia Saudita. Consecuentemente, las probabilidades de abrir el documento por parte de una posible víctima aumentan significativamente.

Script 2: b4c20b56059a6c6762b4c99d04eb9177cb0a4707c58ef575817fb8b702f162aa

Este fichero en Virus Total posee una detección baja, 2/56, y el último análisis ha tenido lugar el 01/12/2018.

En este caso el fichero ha sido subido desde Palestina a Virus Total:

En la imagen se puede que se ha subido a través de la web, desde PS (Palestina) y además que ha sido subido por primera vez el 25/08/2018.

La comunicación de red en este caso se produce también por HTTP al dominio micorsoft[.]store al puerto tcp/2082.

En este caso el script tiene exactamente el mismo código que el hash “617bbc71e5f0a645cbb8eeb6d4a1ece96ba0860c8ab5deda6a795e6ad244607a”. Lo único que varía es el documento señuelo (“decoy”) que podemos ver a continuación:

Las informaciones expuestas en el documento están directamente relacionadas con cuestiones de seguridad y asuntos de política interna de Palestina. Los actores principales mencionados en el texto son Hamas, Al Fatah y el gobierno palestino. La información es un resumen analítico sobre la actual situación política de Palestina e incluso analiza en términos geoestratégicos algunos aspectos de la actualidad. Además, el documento informa sobre las potenciales estrategias políticas que podrían emprender en un futuro los actores mencionados anteriormente. Este tipo de informaciones son de alta relevancia para diplomáticos con intereses políticos en la zona geográfica de Gaza y Palestina. Consecuentemente, podría ser factible que el “target” del documento fueran diplomáticos, políticos y profesionales del sector de defensa.

Script 3: b906f3c19c19e1b20b2d00bfb82b5453d5386d63b4db901ecade0f33dd38326a

Este fichero en Virus Total posee una detección baja, 3/56, y el último análisis ha tenido lugar el 01/12/2018.

En este caso el fichero ha sido subido desde Suecia a Virus Total:

En la imagen se puede confirmar que se ha subido por la community, desde SE (Suecia) y además que ha sido subido por primera vez el 06/11/2018.

La comunicación de red en este caso se produce también por HTTP al dominio micorsoft[.]store al puerto TCP/2082.

En este caso el script tiene exactamente el mismo código que los dos anteriores; el documento señuelo es idéntico a “617bbc71e5f0a645cbb8eeb6d4a1ece96ba0860c8ab5deda6a795e6ad244607a”, variando sólo desde donde ha sido subido y las fechas respecto al primero.

Script 4: 3d4a9466e9428ccb1cde05336f5366b29c7e5ae454ddaa4aa28c75c504c13d96

Este fichero en Virus Total posee una detección baja, 8/56, y el último análisis ha tenido lugar el 12/12/2018. Este documento podemos ver que posee una detección superior al resto, aunque es cierto que alguno no ha sido reanalizado el día 12 de diciembre.

En este caso el fichero ha sido subido desde Palestina a Virus Total:

En la imagen se puede ver que se ha subido a través de la web, desde PS (Palestina) y además que ha sido subido por primera vez el 25/08/2018. La fecha de subida coincide con la fecha del hash “b4c20b56059a6c6762b4c99d04eb9177cb0a4707c58ef575817fb8b702f162aa”.

La comunicación de red en este caso se produce por HTTP al dominio office365-update[.]co al puerto TCP/2082. Este hash cambia el dominio y después la estructura del script es diferente a los demás, aunque mantiene funciones y similitudes con el resto.

La direcciones ip a las que ha resuelto el dominio son:

• 104.24.108.64
• 104.24.109.64

En este caso el dominio siempre ha resuelto a CloudFlare y no se ha observado que haya resuelto a otra dirección ip como en el caso anterior.

El main del script es simple y vamos a ir revisando su flujo:

Vamos a ir viendo que lógica tiene cada una de las funciones.

La primera función que encontramos es writeTXT():

La función lo que hace es guardar, en un fichero de nombre sys.txt y en una ruta fijada desde el script, el contenido de la variable fileContent que es parte de un script en powershell. Hay que destacar que la función de escritura a fichero utilizada es wirteFile(), en la que como se puede apreciar se ha producido un error tipográfico que se ha visto en varios de los scripts que implementan esta funcionalidad.

La función writeSCT():

La función crea un fichero SCT (scriptlet) en disco para ejecutar a través del lenguaje JScript un powershell cuyo código está en el fichero TXT escrito por la función writeTXT().

Para disparar la ejecución se utiliza regsvr32.exe:

La función writeDOC() realiza la misma lógica que en el hash “617bbc71e5f0a645cbb8eeb6d4a1ece96ba0860c8ab5deda6a795e6ad244607a” y que ya ha sido explicada.
En este caso el documento señuelo mostrado a la víctima es el mismo que el presentado en “b4c20b56059a6c6762b4c99d04eb9177cb0a4707c58ef575817fb8b702f162aa”.

Script 5: 4f5d633604b8a3cceb7d582bab640d47e8a5898458c5c2f0e28adcdf01aabf33

Este fichero tiene una tasa de detección más alta que los anteriores: se puede ver que 20/58 antivirus lo identifican como dañino.

En la imagen se puede ver que se ha subido a través de API, desde US (Estados Unidos) y además que ha sido subido por primera vez el 02/09/2018. La fecha de subida es posterior los artefactos subidos desde Palestina, pero cercana en el tiempo.

En este caso se puede ver una referencia a este script en un tweet (https://twitter.com/ItsReallyNick/status/1036687952544448512) de Nick Carr (@ItsReallyNick), donde detalla todos los aspectos técnicos del script:

Viendo el hilo del tweet se puede ver como indican que en este caso se ejecuta un VBScript #Houdini RAT y que el servidor de mando y control es hxxp://149.28.14[.]103:535/is-ready.
Al buscar qué dominios han resuelto a esta dirección ip se observa que el único categorizado como malware es el relacionado con spdns.de y buscando por este nombre de dominio llegamos al análisis https://gist.github.com/JohnLaTwC/ccdcbeb85649ef9feaae045482d694b9 (de @ JohnLaTwC) que se ve como está ese dominio configurado con el puerto 535 y con peticiones HTTP del RAT Houdini. El dominio estuvo resolviendo a direcciones IP hasta el día 30 de Agosto de 2018.

El hecho de que en este caso el actor utilice un Houdini varía respecto al resto de VBS encontrados, que basaban su ejecución en un script powershell que recibía comandos desde un servidor remoto y los ejecutaba, pero aun así son varios los aspectos que nos llevan a pensar que se trata del mismo actor:

• Existen nombres de función que coinciden: writeTXT, writeDOC, wirteFile (esta es un indicador muy importante dado que es el mismo error tipográfico), writeBytes y decodeBase64.
• Después writeDOC tiene la misma lógica y además el documento señuelo está también en árabe.

En este caso el documento señuelo (“decoy”) varía respecto a los anteriores por lo que todo hace presuponer que el objetivo es diferente:

El documento hace referencia a informaciones relacionadas con las Fuerzas de Seguridad en el territorio del norte de Gaza involucradas con la defensa de la frontera. Las informaciones hacen referencia a una acreditación y condecoración por parte de las autoridades gubernamentales palestinas hacia sus miembros de las Fuerzas del orden y cuerpos de seguridad. El “target” de este documento malicioso podrían ser militares, policías, profesionales vinculados al Ministerio de Defensa y miembros del cuerpo diplomático en Gaza. El actual gobierno dentro de la Franja de Gaza es Hamas, un partido que dispone de un brazo militar considerado por diferentes países como grupo terrorista.

Indicadores de compromiso

La entrada Grupo WIRTE atacando a Oriente Medio aparece primero en Security Art Work.

Además de las dos unidades anteriores, que han cobrado protagonismo a partir de la información sacada a la luz en 2018, el GRU cuenta con otras Unidades Militares ligadas a inteligencia de señales, ciberseguridad o guerra de información; algunas de las que podemos encontrar datos en fuentes públicas son las siguientes:

• Unidad Militar 11135 (18th Central Research Institute). Históricamente ([1]) se ha identificado dentro del GRU al Central Scientific Research Institute, que desde Moscú diseña equipamiento SIGINT para el GRU y que quizás en la actualidad sea esta Unidad Militar, focalizada hoy en día no sólo en interceptación de comunicaciones de radio y satélite sino también en dispositivos inalámbricos, sistemas SCADA o protección de las comunicaciones ([2]).
• Unidad Militar 40904, conocida como el “177º Centro Independiente para la Gestión del Desarrollo Tecnológico”. Ubicada en Meshcheryakova, 2 (Moscú), con alta probabilidad, esta unidad se especializa en el procesamiento de inteligencia de señales ([3]).
• Unidad Militar 36360. Aparentemente es una unidad formativa del GRU en la que se imparten, el menos desde enero de 1949, cursos avanzados de inteligencia. Esta formación, también aparentemente y según fuentes abiertas, incluye temas muy ligados al ámbito ciber como los siguientes:
  • Ingeniería de Telecomunicaciones (comunicación por radio, radiodifusión y televisión). 
  • Tecnologías, redes y sistemas de comunicación.
  • Sistemas y tecnologías de información: información y análisis.
  • Ingeniería de software.
  • Matemáticas aplicadas y ciencias de la computación. 
  • Seguridad de la información. 
  • Software informático. 
  • Sistemas automatizados de procesamiento y control de información. 
  • Traducción y estudios de traducción (lingüística).
• Unidad Militar 54726 (46th Central Research Institute), centro focalizado en información técnica militar, en especial sobre las capacidades de países extranjeros, que potencialmente incluye investigación en el ámbito ciber.

Por último, es necesario recordar que el GRU es una pieza más -importante, muy importante, pero una pieza más- en la estructura ciber del Ministerio de Defensa (MOD) ruso; así, adicionalmente a las anteriores en las Fuerazas Armadas rusas otras Unidades Militares cuyo trabajo tiene algo que ver con el ámbito ciber que nos ocupa; algunas de ellas, también a partir de la información disponible en fuentes públicas, son las siguientes:

• Unidad Militar 31659, no sabemos si ligada al GRU o directamente al MOD ruso pero destinataria de partidas para la protección ciber (por ejemplo mediante software antivirus) del MOD. Personal de esta unidad ha participado en publicaciones científicas públicas relativas a ciberseguridad, en especial en el ámbito defensivo y de protección (como la detección de anomalías). 
• Unidad Militar 01168 (27th Central Research Institute), creado en 1954 y convertido en 1961 en CRI, fue el primer centro de cálculo soviético ([2]). No es una unidad militar del GRU sino que pertenece directamente al Ministerio de Defensa ruso y según fuentes abiertas ha trabajado en desinformación a través de Internet.
• Unidad Militar 96010 (Federal Service for Technical and Export Control, FSTEC), que controla la exportación de tecnología sensible y protege redes y sistemas informáticos ([2]).
• Unidades Militares 21882, 77111 y 33872, que conforman la estructura de guerra electrónica del MOD.
• Unidad Militar 40056 del MOD ruso, una Unidad curiosa conocida como “Dirección Principal de Investigación Submarina”, que analiza entre otras las capacidades civiles extranjeras en cableado submarino ([4]) y desarrolla capacidades propias para vulnerar dicho cableado.

Referencias

[1] Desmond Ball, Robert Windrem. Soviet signals intelligence (SIGINT): Organization and management. Intelligence and National Security. Volumen 4, Issue 4. 1989.

[2] Jeffrey Carr. Inside Cyber Warfare: Mapping the Cyber Underworld. 2nd edition. Ed. O’Reilly, 2011.

[3] RFE/RL. Investigative Report: On The Trail Of The 12 Indicted Russian Intelligence Officers. Julio, 2018. https://www.rferl.org/a/investigative-report-on-the-trail-of-the-12-indicted-russian-intelligence-officers/29376821.html

[4] Keir Giles. Handbook of Russian Information Warfare. NATO Defense College. Noviembre, 2016.

La entrada (Ciber) GRU (IX): estructura. Otras unidades aparece primero en Security Art Work.

Técnica y herramienta para la obtención de credenciales de usuario del aplicativo SAP

En este artículo se va a hablar del protocolo que usa SAP cuando un usuario se autentica, los fallos de seguridad que presenta, y cómo poder utilizarlo en nuestro beneficio al llevar a cabo una auditoría.

Con el crecimiento de las empresas, surge la necesidad de emplear nuevas herramientas que permiten hacer una mejor gestión del capital, tanto humano, como físico.

Así, compañías como SAP ponen a disposición de otras empresas una herramienta que les permite poder llevar a cabo esta gestión. Aunque hay varios tipos de arquitectura, lo más común es encontrarse una configuración basada en tres niveles (three-tier architecture).

Esta estructura plantea un modelo en el que los clientes (client tier) se conectan a uno o varios servidores (business logic tier), que hacen de mediadores entre el usuario y las bases de datos (database tier), que puede estar distribuida entre varias máquinas.

Dentro de esta distribución se usan distintos protocolos para la comunicación, en función de los activos que tomen parte en ella.

• • DIAG: se utiliza durante la comunicación entre un cliente y un servidor.
  • RFC: es el protocolo que se usa en la comunicación entre servidores.
  • HTTP/HTTPS: estándar utilizado para aquellos servicios web que hacen uso de la aplicación, así como del acceso a través de un navegador al aplicativo.

Para este artículo se va a centrar la atención en el primer protocolo, DIAG. Partiendo del escenario propuesto, 3-tier architecture, el proceso (resumido) que se lleva a cabo cuando un usuario hace uso de la aplicación, es el siguiente:

1. Los usuarios, a través de la aplicación SAP Logon, se autentican usando su usuario y contraseña, contra servidor 1. En una empresa puede haber varias aplicaciones dentro de SAP (recursos humanos, contabilidad, proyectos…), y que un usuario solo pueda tener acceso a alguno/s de ellos. En este tipo de conexión se utiliza el protocolo DIAG o SAPDIAG.
2. Una vez autenticado el usuario, el servidor 1 consulta con el servidor 2 que aloja la base de datos la información que tiene que mostrar al usuario. Protocolo RFC.
3. El servidor 3 devuelve la información solicitada al servidor 1 (que es el que ha realizado la autenticación). Protocolo RFC.
4. Se le envía al usuario la información mediante el protocolo DIAG.

En el paso 1, se está enviando al servidor las credenciales del usuario haciendo uso de un protocolo que es propietario de SAP, habiendo hecho su propia implementación. El problema que tiene este protocolo es que aplica un algoritmo de compresión para reducir el tamaño de la petición y, presumiblemente, para ofuscar su contenido. Esto quiere decir que aplicando el mismo algoritmo de descompresión se podría leer el tráfico ya que no está cifrado. Con respecto a esto, se han realizado varias investigaciones que permiten llevar a cabo esta descompresión. El equipo de SecureAuthCorp son los que más han avanzado en este campo. Tienen varias herramientas que son muy útiles a la hora de auditar una organización que cuenta con SAP, siendo una de ellas un plugin de Wireshark, que es del que se va a hablar a continuación.

Para llevar a cabo este ataque, es necesario, o bien que se haga creer a los usuarios que nuestra máquina es el servidor de SAP para que se le envíen las credenciales, o bien se ha vulnerado el equipo de un usuario o un servidor de SAP. No se va a tratar aquí el procedimiento para llegar hasta estos escenarios.

Suponiendo que se ha conseguido vulnerar una máquina de un usuario, se realiza en primer lugar un volcado del tráfico de red que esté intercambiando (en el caso de estar capturando el tráfico en un servidor, cuidado con la cantidad de tráfico que se captura pues se puede puede generar un fichero muy grande en muy poco tiempo llegando a agotar la memoria del disco).

• -I eth0 → se intercepta de la interfaz de red que está usando
• -w output.pcap → se escribe en un fichero para su posterior tratamiento
• dst X.X.X.X → dirección del servidor de SAP
• dst port 3200 → puerto comunmente utilizado en este protocolo. Puede variar, ya que los dos últimos dígitos dependen de la instancia del servidor (3200, 3201, 3202…)

Una vez que se ha capturado una cantidad de tráfico deseada, se importa el fichero al equipo del auditor, donde se procederá a su lectura.

Aunque en el repositorio de github se dan las instrucciones para incluir el plugin en Wireshark, se ha creado un docker para ahorrar tiempo a los auditores. Se puede encontrar aquí.

Una vez se ha instalado, se abre la herramienta, se carga el archivo con el tráfico que se ha capturado y se filtran los paquetes utilizando la siguiente regla:

Si se ha capturado tráfico del protocolo SAPDIAG (el que se está buscando), que contienen (o pueden contener) usuarios y contraseñas, aparecerán varios paquetes al aplicar el filtro, como se puede apreciar en la captura:

Ahora, se selecciona, de las pestañas de abajo, la que se llama Uncompressed Data, y se exploran los paquetes cuyo destino es el servidor de SAP, en busca de las credenciales que se quieren obtener:

De los elementos marcados, el primero indicaría el usuario, y el segundo la contraseña. Esta última, se encuentra precedida por un paréntesis, es importante prestar atención a esto, para no considerar este carácter como uno más de la clave.

Como se ha visto, SAP utiliza por defecto un protocolo de comunicación débil para transportar información sensible. Aunque es posible hacer que el tráfico vaya cifrado, es necesario obtener un componente extra, conocido como SNC y que, aparentemente, requiere de una instalación un poco tediosa.

Esperemos que la rutina y herramienta comentadas, os puedan ser útil en vuestras auditorías. Y si queréis que se hable sobre alguna otra herramienta o aspecto de seguridad de SAP, ponédnoslo en los comentarios.

Fuentes y referencias:

• • • http://itsecx.fhstp.ac.at/downloads_2011/04_Riley.pdf
    • https://github.com/SecureAuthCorp/SAP-Dissection-plug-in-for-Wireshark

La entrada ¿Qué paSAP con mis contraseñas? aparece primero en Security Art Work.

[Nota: Esta serie de posts es una narración de un análisis forense de un caso práctico totalmente ficticio (pero contada, esperamos, de forma didáctica y con gracia y salero). Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en las XII Jornadas STIC del CCN-CERT, o echar un ojo las slides de la presentación].

[Nota 2: Estos posts desgranan un taller de análisis forense básico. Habrá algunas cosas que se podrían hacer de manera más eficiente y elegante, pero la idea era hacerlas de forma sencilla para que fueran fáciles de entender. Y como todo buen taller práctico, se puede seguir paso a paso: el CCN-CERT está alojando en LORETO todo el material, que podéis descargar desde aquí. Tenéis tanto las evidencias en bruto (si queréis primero intentar encontrar el bicho por vuestra cuenta sin leer nada de la solución) como una guía paso a paso con todas las herramientas y evidencias necesarias en cada paso].

Un nuevo día empieza en las instalaciones del MINAF (Ministerio de la Alegría y la Felicidad), lo que para Ángela de la Guarda (CISO del MINAF) significa café, reuniones y papeleo. Al menos, el proyecto del ENF (Esquema Nacional de Felicidad) está de una vez saliendo adelante…

Pero poco dura la alegría en casa del pobre. El CAU llama porque tienen un ticket que no saben por dónde cogerlo: María Feliz (Subdirectora General de Festejos) se queja amarga (e irónicamente) de que su correo “lleva un rato haciendo cosas raras”. Magnífica descripción del problema, afirmo, piensa mientras termina el café. El CAU ha revisado su equipo y no ha encontrado nada fuera de lo normal, pero la Subdirectora insiste en que “le aparecen correos como leídos que ella no ha abierto”.

Esta afirmación despierta el sexto sentido de Ángela, y decide poner a uno sus técnicos a investigar un poco más en profundidad el asunto. Quince minutos más tarde el técnico (Salvador Bendito), llama nervioso y excitado a partes iguales: ¡tenemos un incidente! Alguien ha accedido a la cuenta de correo de la Subdirectora a través del webmail del MINAF, usando para ello unas direcciones IP no pertenecientes a ningún ISP español.

La cosa no queda ahí: a lo largo de todo el día se ha accedido desde la misma dirección IP a varias cuentas de correo de altos cargos del MINAF, con varios centenares de accesos. Un análisis de los logs del servidor de correo permite establecer esta línea temporal inicial relativa al 3 de Noviembre de 2018 (día del incidente):

• 11:35h – Primer acceso de la IP sospechosa al webmail de maria.feliz.
• 11:35h-16.00h – Accesos de la IP a diversas cuentas de correo de altos cargos.
• 16.00h – Detección del incidente.

El paciente cero resulta ser Pepe Contento (Subdirector General Adjunto de Alborozo) con un primer acceso a su cuenta de correo sobre las 11.15h, así que corresponde investigar a fondo su equipo para determinar si es la causa del incidente (se ha decidido no bloquear el acceso de los atacantes a los correos hasta que no se tenga más información de la extensión y gravedad del ataque). Ángela y Salvador sorprenden al Subdirector justo cuando estaba cerrando su despacho, y cuando es consciente de la gravedad del incidente se pone a disposición de los técnicos para todo aquello que necesiten.

La política de seguridad del MINAF es muy clara: en caso de un incidente de seguridad, el personal de ciberseguridad tiene la potestad de examinar cualquier equipo o sistema de la Organización. En este caso no hay problema alguno, ya que el Subdirector ofrece encantado su consentimiento para el examen, llegando a quedarse en el despacho mirando con fascinación a los técnicos haciendo su trabajo.

En estos casos la medida más eficiente es realizar una captura de evidencias en caliente, ya que pueden realizarse de forma rápida y de esta forma se agiliza la respuesta al incidente. El Subdirector desbloquea su equipo con su contraseña y Salvador lanza un terminal elevado con la contraseña de administrador local que le ha facilitado el CAU.

A continuación pincha una memoria USB con las herramientas que va a emplear: winpmem para realizar un volcado de la memoria RAM del equipo y CyLR para la recogida de datos de triage, siempre teniendo cuidado de que los resultados se guardan en el USB y no en el disco duro local. La operación dura menos de 5 minutos (rapidísimo si lo comparamos con las 4-6 horas que puede suponer el clonado forense de un disco duro de 1Tb).

Una vez realizada la adquisición de evidencias en caliente, toca apagar el equipo con la metodología habitual: Ángela le dice al Subdirector que mire hacia un lado mientras Salvador se acerca a la parte de atrás de la torre y, de forma súbita, tira del cable de alimentación del equipo. Nunca se sabe qué scripts se pueden ejecutar en el apagado del equipo…

Habiendo realizado la adquisición inicial, se calculan en el portátil de Salvador los hashes de los dos ficheros obtenidos mediante la herramienta HashMyFiles:

MINAF-PC1.zip
MD5 a15acf19045c1f92a7b2eef46e1ed9d5
SHA1 fab756da558d6c7584574d7d73d62adf4e82bf16
SHA256 956b1366851608fe253deb3f14f7d013c24011dd940db9e2c96ffd4bb4e6c1b2

MINAF-PC1_Triage.zip
MD5 b52276522f5cbcc7f3fd5b300992e151
SHA1 454b8d3fe72ea778c78251f9662c5c565dc65414
SHA256 c7a405cedeb5b20046dee49f08dab5521d51d80b8f7334c5c4742329b465c93a

Para asegurar las evidencias, se realizan dos copias adicionales: una en el portátil de Salvador y otra en otra memoria USB nueva que Ángela ha traído para la ocasión (que se entrega junto con el equipo del Subdirector a la Inspección General de Servicios para su custodia). Se documenta todo el proceso (ver Ficha_Adquisición_Evidencias.txt contenido en el fichero Forense_MINAF_full.zip) y los técnicos vuelven a su despacho para comenzar el análisis.

[Nota 3: En la realidad todo el entorno de pruebas está virtualizado en un Proxmox en remoto al que pinchar USB es un verdadero dolor. Es por ello que la captura se ha hecho en “modo cloud”: se ha añadido al equipo un disco duro con las herramientas, se han ejecutado y se ha retirado el disco. Esto no afecta significativamente al análisis, pero es necesario indicarlo para no inducir a confusión si un analista examina las evidencias en bruto].

El primer paso es validar las evidencias recibidas con la herramienta HashMyFiles que Ángela tiene en su equipo:

Todo parece en orden, así que se puede comenzar el análisis.

Paso 1: Prefetch

Ángela tiene predilección por empezar los forenses revisando la carpeta Prefetch, con toda la razón del mundo: cada vez que se ejecuta una aplicación, Windows determina una serie de datos que necesita para arrancar y los deja precargados para acelerar futuras ejecuciones.

Esta funcionalidad está disponible desde Windows XP, aunque no existe ni en servidores ni en equipos con discos duros SSD (en los que Windows dice que son tan rápidos que no merece la pena). Y aunque su objetivo sea beneficiar la experiencia de usuario, para un analista forense son oro puro porque nos permiten determinar qué se ha ejecutado en el equipo.

Ángela hace uso de WinPrefetchView para cargar la carpeta Prefetch obtenida en el triage vía CyLR, y encuentra una buena lista de aplicaciones. Pero antes de nada, revisa la configuración horaria de la herramienta para asegurarse de que está trabajando en UTC (Coordinated Universal Time).

Un detalle muy importante siempre que realicemos un análisis forense es el tema de la gestión de las timezones: todos los países tienen una hora relativa a lo que se denomina UTC (GMT y UTC son para los mortales lo mismo). Por ejemplo, España es UTC+1 (salvo en verano que es UTC+2).

Una mala gestión de las timezones puede hacer perder mucho tiempo en un análisis forense, ya que se terminan buscando evidencias en momentos en los que no se han producido, pudiendo incluso llegar a conclusiones erróneas.

Los buenos forenses hacen dos cosas: intentan trabajar SIEMPRE en UTC+0, y sobre todo se conocen las herramientas que usan y saben en qué timezone trabajan por defecto, y si se pueden poner o no en UTC+0. Ángela es la CISO del MINAF pero se maneja con un terminal igual de bien que con un Excel, así que lo primero que hace es acceder a Options y comprobar que se muestran los tiempos en GMT (como ya hemos dicho, equivalente a UTC+0).

A continuación Ángela se pone a buscar qué se ha arrancado en el equipo antes de las 10.15h (recuerda, como estamos en UTC+1 para pasar a UTC+0 tenemos que restar una hora), prestando especial atención tanto a programas de ofimática (Word, Outlook, Excel) como a los ya conocidos LOLbins (comandos de Windows que permiten ejecutar código, en algunos casos incluso descargado de Internet).

[Tip: otra aproximación muy interesante suele ser la de ordenar por ejecuciones con el “Run Counter” y ver qué es lo que menos se ha ejecutado en el equipo].

Ángela tarda 30 segundos en encontrar algo MUY sospechoso: un combo a las 10.05h de wscript.exe + rundll32.exe, que podría ser una ejecución maliciosa.

Si nos fijamos en el panel inferior de WinPrefetchView, para cada ejecutable tenemos un listado de lo que se ha almacenado, y aquí la cosa queda bien clara:

El ejecutable wscript.exe ha lanzado el script FELICIDAD.JS… que si nos fijamos en la ruta está en “Temporary Internet Files”, lo que indica que ha sido descargado desde Internet.

En este punto Ángela ya tiene fuertes indicios de que el equipo ha sido comprometido, y además tiene algo valiosísimo: su primer IOC (Indicator of Compromise o Indicador de Compromiso), un fragmento de información que es vital para determinar si otros equipos de la Organización han sido afectados.

El IOC en palabras se podría describir como “presencia del fichero FELICIDAD.JS en un directorio de usuario”, algo que se puede fácilmente programar como un script .bat y ejecutar vía GPO/SCCM en todos los equipos de la Organización, volcando los resultados a una unidad de red compartida para su análisis.

El paso a seguir está claro: dado que el fichero malicioso parece haber sido descargado desde Internet, vamos a analizar el historial de navegación del usuario.

Paso 2: Navegación del usuario

Si revisamos con un poco más de detalle la salida de WinPrefetchView podemos observar que el navegador empleado ha sido Internet Explorer (IEXPLORE.EXE a las 10.01h), por lo que nos vamos a centrar en obtener su navegación.

El historial de navegación de un Internet Explorer moderno (el equipo es un Windows 7 correctamente actualizado) se guarda dentro del perfil de cada usuario en la carpeta:

C:\users\[username]\AppData\Local\Microsoft\Windows\WebCache

Actualmente hay herramientas como BrowsingHistoryView o MyLastSearch que pueden extraer la navegación del perfil de usuario, pero en este caso CyLR ha sido especialmente parco y nos ha facilitado únicamente el directorio Webcache, por lo que estas herramientas nos proporcionan un directorio vacío (parece que necesitan alguna estructura de ficheros para funcionar de forma correcta).

Ángela lleva unos cuantos forenses entre pecho y espalda, y sabe que siempre hay una forma de obtener resultados si conoces cómo funcionan las cosas a bajo nivel. En realidad un Internet Explorer moderno (versión 10+) guarda todos los datos de usuario en el fichero WebCacheV01.dat, que es una base de datos ESE (Extensible Storage Engine). Si tenemos un software que nos permita abrir ficheros ESE vamos a poder acceder a los datos en bruto, algo que Ángela consigue usando ESEDatabaseView:

El visor nos da acceso a bajo nivel a los datos, pero en un formato razonablemente usable. Ángela vuelve a ser cuidadosa con las timezones, y a través del menú “Options” se asegura de que la opción de “Convert Date/Time from GMT to Localtime” está desmarcada para así poder trabajar en UTC. Un vistazo rápido nos permite identificar que el historial reside en el contenedor con id=2, por lo que podemos navegar con la herramienta a esa tabla.

Una vez en el historial Ángela tiene una hipótesis muy clara: si wscript.exe se ejecutó el 3 de Noviembre a las 10:50:12h, en el historial de navegación tiene que existir una entrada sobre esa hora que nos indique a qué URL se ha accedido. Y en efecto, Ángela tiene razón:

Premio gordo. El usuario pepe.contento ha accedido a la URL:

http://sharepoint.mina.es:8000/felicidad.html

Al encontrar este dominio Ángela profiere una sarta de insultos que haría sonrojar a un estibador marsellés. Los atacantes han suplantado el Sharepoint del MINAF… por un dominio antiguo del MINAF. El Ministerio tenía anteriormente la denominación de MINA (Ministerio de la Alegría y la Felicidad), pero con el último cambio de gobierno se decidió incluir a la Felicidad como nueva competencia y por ello se produjo el cambio de nombre. Dado que nadie se molestó en renovar el dominio, los atacantes se dieron cuenta, lo registraron y emplearon vilmente para el ataque (si los usuarios se fijan habitualmente poco en los nombres de dominio, mucho menos en uno que han visto mil veces y que además reconocen como propio).

Algo bueno tiene esta pena: Ángela tiene un nuevo IOC, en este caso de los que llamamos “pata negra” ya que son fáciles de aplicar y con un alto grado de fiabilidad (no hay un motivo razonable para que un cliente visite ese enlace sin estar afectado por el ataque).

Ángela comprueba los logs de su proxy de navegación y su cortafuegos y respira aliviada. Por ahora el usuario pepe.contento parece que ha sido el único afectado. Le queda una de las dudas clásicas: ¿bloquea el dominio ahora mismo, o espera a saber más del incidente a riesgo de que los atacantes puedan causar más daño? Ángela es de la vieja escuela, y sabe que un “cierre” mal ejecutado es como tomar antibióticos dos días: corres el riesgo de no solo no matar al bicho sino de hacerlo más fuerte (avisas a los adversarios de que los has detectado y pueden tomar medidas evasivas), así que decide esperar al menos hasta terminar el análisis forense.

El contenido de los logs (y alguna sorpresa que otra) en la siguiente entrada…

La entrada Agujas, pajares e imanes: Análisis forense de malware fileless (I) aparece primero en Security Art Work.

Paso 3: Logs de eventos

En la entrada anterior dejamos a Ángela blasfemando por la manera en la que los atacantes habían empleado un antiguo dominio del MINAF para realizar su ataque. Ahora toca comprobar lo sigilosos que han sido revisando los logs del sistema.

Todo equipo Windows tiene un registro de eventos, situado en los equipos modernos en:

C:\Windows\System32\winevt\Logs

Existen diversos registros en función de los eventos que se guardan. Los clásicos son Seguridad, Sistema y Aplicación, pero a día de hoy tenemos varias docenas más de registros, que en algunos casos nos pueden dar información vital. Estos registros se guardan en formato binario, por lo que necesitamos algún programa para abrirlos.

Lo más profesional sería emplear LogParser, pero Ángela sabe que el humilde Visor de Eventos suele ser en muchos casos más que suficiente (y que puede abrir tanto los logs del propio equipo como los de otros equipos). En primer lugar, tenemos que gestionar las timezones. En este caso el Visor de Eventos trabaja con la hora del propio equipo, por lo que estaremos en UTC+1 y por ello tendremos que buscar actividad sospechosa el 3 de Noviembre alrededor de las 11.00h.

Todo evento que se guarda en un log de Windows tiene un identificador de evento (EventID) que permite identificar numéricamente a todos los eventos en Windows (aunque puede diferir en cada versión de Windows, por lo que siempre se aconseja el contrastar la información).

El log de Security suele ser el más jugoso, ya que contiene los inicios de sesión (EventID 4624), pero suele ser el más volátil ya que suele estar lleno de eventos y el tamaño por defecto es muy pequeño (en el MINAF suelen almacenar 3-4 días de eventos). Además hay que tener en cuenta que son blanco habitual para los atacantes, que los borran sin remordimientos para cubrir sus huellas.

Por eso mismo Ángela tiene un as en la manga: el humilde y trabajador log de perfiles de usuario (Microsoft-Windows-User Profile Service%4Operational.evtx), que guarda todas las operaciones relacionadas con los perfiles de usuario. Cada vez que se inicia sesión en un equipo (ya sea en local o en dominio) se carga el perfil del usuario (si alguna vez has iniciado por primera vez sesión en un Windows a lo mejor te suena unas ventanitas pequeñas que aparecen en la esquina superior izquierda que dicen “Configurando XXX” … ese es tu perfil de usuario siendo creado).

La buena noticia es que cada vez que se carga un perfil de usuario se genera un evento con EventID 5. El hecho de que este log sea muy específico hace que tenga una alta durabilidad, sumado a que suele pasar desapercibido a los atacantes, lo convierte en uno de los mejores amigos de un analista forense.

Analizando este log encontramos una pieza de información interesante:

Al parecer poco antes de la actividad maliciosa la cuenta dom.adm (un administrador de dominio) había iniciado sesión en el equipo, un dato significativo que genera múltiples preguntas: ¿Habrán conseguido los atacantes las credenciales del administrador de dominio? ¿Qué hacía exactamente esa cuenta en ese equipo minutos antes del incidente?

Otro de los logs que suele dar buenas pistas es el de Sistema, que almacena todo lo relevante que ocurre en el equipo. En este caso Ángela encuentra una prueba bastante contundente de que el equipo está comprometido:

¿Un servicio con nombre aleatorio y además recién instalado en el sistema y con un cmd.exe? ¡Qué me estás contando! Si Ángela tenía alguna duda de si este equipo estaba o no comprometido quedan disipadas al ver este log. Ahora que sabe a ciencia cierta que el equipo tiene “premio” Ángela sabe lo que tiene que hacer: ir de caza.

Paso 4: Persistencia

Buena parte de los atacantes pretenden permanecer en un sistema comprometido durante mucho tiempo. Para ello necesitan obtener persistencia, que en nuestro ámbito es la capacidad de seguir ejecutándose en el equipo, sobreviviendo incluso a un reinicio.

Existen diversos mecanismos de persistencia (claves Run, tareas programadas, servicios, eventos WMI), pero todas ellas tienen algo en común: se almacenan en el registro de Windows. Tenemos dos tipos principales de persistencia: en espacio de usuario (cuando el atacante no tiene privilegios de administrador) y en espacio de sistema (cuando el atacante ha conseguido privilegios de administrador).

El análisis de los diversos mecanismos de persistencia es fundamental en un análisis forense, ya que si localizamos la persistencia, estamos localizando de forma efectiva el malware de los atacantes. Una herramienta muy útil para analizar los mecanismos de persistencia es Autoruns, pero nos da problemas para ejecutarla con la escasa información que recoge CyLR.

Ángela suspira y se remanga la camisa: va a tocar hacer las cosas de forma manual con RegRipper, la herramienta forense casi por defecto de análisis del registro de Windows. En este caso se lleva una grata sorpresa al encontrar que RegRipper tiene un interface gráfico (a lo mejor lo tenía desde hace años, es la costumbre de la línea de comandos).

Obtener resultados de todos los plugins de RegRipper es tan sencillo como lanzarlo primero sobre el hive SOFTWARE del registro (donde está el HKLM, espacio de sistema) y a continuación sobre cada uno de los hive NTUSER.DAT de cada usuario (donde está el HKCU, espacio de usuario).

Ángela decide analizar los resultados por orden de probabilidad. Aunque hay mecanismos muy complejos que permiten conseguir persistencia, el uso de claves Run está muy extendido por su sencillez y rapidez. En el caso de RegRipper obtenemos esos valores con los plugins soft_run (SOFTWARE) y user_run (NTUSER.DAT). Una revisión rápida permite comprobar que no tenemos nada ejecutándose al inicio del equipo:

En el caso de los usuarios, la cosa es “ligeramente” distinta:

Ángela agita el puño en el aire conteniendo un “te pillé hijo de p…”. Lo que se ve con prístina claridad es un script de Powershell que se ejecuta desde la clave “Felicidad 2.0” (un nombre sospechosamente parecido a una aplicación interna del MINAF) que carga su contenido desde otra clave del registro, Felicisoft.

Para comprobar el contenido de esa clave Ángela hace uso de RegistryExplorer, que permite cargar hives del registro offline, en este caso la del usuario pepe.contento. El resultado habla por sí mismo:

Dentro de la clave Felicisoft tenemos la variable Happisoft, que en nuestro caso contiene un chorizo de letras y números… que cualquier ojo entrenado como el de Ángela reconoce automáticamente como codificado en base64.

Este análisis ha sido especialmente provechoso, ya que hemos obtenido lo que sospechamos: el malware que se arranca en el inicio de sesión del usuario pepe.contento (ojo, al ser persistencia en espacio de usuario tan solo se ejecuta cuando el usuario en cuestión inicia sesión).

Pero además tenemos otra joya: un IOC de alta calidad que nos permite determinar con certeza si un equipo o no está comprometido. En este caso el IOC es la existencia de la clave Felicisoft en el registro de usuario, algo que se puede verificar con relativa sencillez (un .bat que ejecute una query con el comando reg, distribuida como GPO en la Organización).

Es la hora de coger ese código base64 y apalearlo hasta que confiese. Ángela sabe que Salvador lleva varios meses haciendo cursos de análisis de malware, así que le va a encargar el análisis mientras ella analiza la memoria del equipo.

Los resultados de ambos análisis (y alguna que otra mala noticia), en la siguiente entrada…

La entrada Agujas, pajares e imanes: Análisis forense de malware fileless (II) aparece primero en Security Art Work.

Paso 5: Análisis de malware

En la entrada anterior Ángela había encontrado la persistencia del malware, así que procede analizarlo para ver su contenido. Salvador (a pesar de su espesa barba digna de un administrador de HP-UX de principios de siglo) está más contento que un niño con zapatos nuevos, así que se lanza a por el malware como un fox-terrier hambriento.

Lo primero de todo es comprobar si nos estamos enfrentando a un malware conocido. Para ello Salvador copia el código en base64 a un fichero de texto, calcula su hash con HashMyFiles y lo sube a VirusTotal sin obtener resultados. Interesante…

El segundo paso sería subir el fichero a VirusTotal, pero Salvador ha estado atento a lo explicado por sus profesores del curso de análisis de malware: algunos atacantes vigilan de forma constante VirusTotal para comprobar si su malware ha sido subido a la plataforma, usándola como un sistema de alerta temprana.

En algunos casos son hasta capaces de poner un código distintivo de cada organización a la que atacan para, cuando descubren que está en VirusTotal, descargarlo y saber exactamente qué cliente los ha detectado (y suele ser MUY mala idea que los malos sepan que les vas pisando los talones…).

Lo que sí que puede hacer es subirlo a MARIA, la solución multiantivirus que el CCN-CERT pone a disposición de todas las AA.PP. (y que obviamente es privada). En este caso el resultado es más bien decepcionante:

Vamos a tener que darle “amor” al bicho, piensa Salvador. Lo primero de todo va a ser decodificar ese código en base64. Para ello hace uso de b64.exe, una utilidad básica que nos convierte el código anterior en un Powershell algo más comprensible. Después de formatearlo un poco para hacerlo más legible, el resultado es el siguiente:

El código viene a decir más o menos: “mira a ver si estás en 32 o 64bits, coge este otro código en base64 que está comprimido, cárgalo en memoria y ejecútalo”. Salvador sabe que podría cargar ese base64 en su Linux y magrearlo con Python, pero también sabe Powershell suficiente como para obligar al bicho a que trabaje para él.

Unas pequeñas modificaciones al código hacen que vuelque la salida del código en base64 a un fichero ¿Y cuál es el resultado de un buen trabajo? Más trabajo, ya que la salida resulta ser OTRO Powershell:

En este caso el Powershell se le escapa a Salvador, pero sí que reconoce otro código en base64 que con toda probabilidad sea el payload malicioso final. Una nueva decodificación nos da como resultado un fichero que ya está en binario, por lo que es muy posible que éste sea el shellcode final que se ejecuta en la memoria.

Es momento de sacar un conejo de la chistera: scdbg.exe, un emulador que permite lanzar un shellcode y trazar las llamadas a la API de Windows que realiza. Y vaya si nos da resultados:

Todo el código que Salvador ha analizado se reduce más o menos a “de la forma más sigilosa posible, conéctate a esa IP y ejecuta en memoria lo que te descargues”. Salvador no puede evitar en cierta medida alabar la técnica de los atacantes: el malware real de los atacantes está escondido en esa IP, y pueden cambiarlo a voluntad siempre que quieran (al coste de una petición HTTPS cada vez que se arranca el equipo, eso sí).

Solo por curiosidad, Salvador vuelve a subir este último fichero a MARIA a ver qué pasa:

Los atacantes lo saben, y Salvador ahora lo ve muy claro: la triple capa de ofuscación en Powershell les funciona a los atacantes MUY bien.

Pero lo más importante que ha sacado Salvador de su análisis es otro IOC “pata negra”: el servidor C2 (Command & Control) de los atacantes. Esta dirección IP puede buscarse tanto en los logs del cortafuegos como en los del proxy para comprobar si tenemos más equipos comprometidos en la Organización.

Paso 6: Análisis de memoria RAM

Mientras Salvador apalea el malware, Ángela se centra en el análisis del volcado de la memoria RAM recuperada del usuario. Una de las ventajas del análisis de memoria es que TODO está en la memoria (conexiones, procesos, ficheros abiertos…), siendo además el lugar en el que menos trucos pueden usar los atacantes para esconderse.

En el análisis de memoria RAM los forenses están divididos entre Volatility y Rekall cual Madrid/Barca, Coca-Cola/Pepsi o concebollismo/sincebollismo, pero Ángela es del Volatility Team. El primer comando que ejecuta es netscan para mostrar las conexiones de red del equipo (lo bueno del análisis de memoria es que no solo están las conexiones actuales del equipo sino que se pueden encontrar algunas conexiones pasadas).

La IP 2.16.65.18 corresponde a Akamai… pero la IP 101.132.122.231 parece un ISP de China, algo MUY sospechoso. Ángela se guarda esa IP (por ahora un potencial IOC), y continua lanzando el comando pstree para obtener un árbol de los procesos del sistema.

A los ojos entrenados de Ángela este resultado es como decir “ha sido el mayordomo, en el salón de fumar y con el candelabro”. Los puntos de la izquierda indican quién es el padre de cada proceso, por lo que según esa imagen ha pasado lo siguiente:

1. Explorer.exe (el explorador de Windows, el proceso base que gestiona la sesión de usuario) lanza Outlook.exe (el cliente de correo).
2. Outlook.exe lanza iexplore.exe (el navegador Internet Explorer), lo que induce a pensar que el usuario ha recibido un correo con un enlace y ha pinchado sobre el mismo.
3. Iexplore.exe ha lanzado wscript.exe (algo que ya sabíamos) ejecutando el JavaScript contenido en felicidad.js.
4. Wscript.exe ha lanzado rundll32.exe (posiblemente el código malicioso final).
5. Rundll32.exe ha lanzado cmd.exe (o el código malicioso final o alguna herramienta de apoyo para los atacantes).

Habiendo localizado el posible código malicioso, Ángela ahora quiere saber si los atacantes han conseguido de alguna forma elevar privilegios (porque ahora mismo tendrían que estar como usuarios pelados ya que han entrado a través del usuario pepe.contento). Para ello puede hacer uso del comando privs, que nos devuelve todos los privilegios que tienen los procesos en ejecución:

Ángela busca por el PID 1100 (el del proceso rundll32.exe), y blasfema en arameo al encontrar que posee el privilegio “SeDebugPrivilege” (que permite al poseedor hacer un debug del resto de procesos del sistema, algo que puede ser usado para inyectar código en su memoria).

¿Cómo han conseguido los atacantes elevar privilegios en el equipo, si la política de parches de seguridad es más rígida que una institutriz inglesa de 1920? (y ella lo sabe perfectamente porque fue ella la que la implantó).

La respuesta la tiene el propio CAU: al parecer algún alto cargo se quejó de que el HappiNator 32.1 no sincronizaba correctamente con la YupiNube en una cuenta de usuario normal, así que sin decirle nada a Seguridad de la Información, les dieron a todos privilegios de administrador local. El facepalm y las ganas de matar de Ángela podrían constituir un meme si alguien hubiera capturado ese momento…

Ángela toma nota del hallazgo y continua con el análisis de la memoria. Otra táctica que suele dar muy buenos resultados es hacer uso del comando malfind (que como su nombre indica encuentra malware en el equipo a base de buscar código inyectado en otros procesos). Suele dar una buena cantidad de falsos positivos pero en este caso queremos saber si el PID 1100 (rundll32.exe) aparece entre los resultados. Afirmativo:

Malfind nos vuelca el resultado del código inyectado en una carpeta, por lo que podemos coger ese trozo de memoria y subirlo a MARIA (podríamos subirlo a VirusTotal porque al ser un trozo de memoria las posibilidades de que los atacantes lo estén monitorizando son prácticamente nulas, pero no vamos a correr riesgos). MARIA parece tener bastante claro a lo que nos estamos enfrentando:

Al parecer tenemos en memoria una preciosa sesión de Meterpreter, herramienta exótica que casi ningún atacante suele emplear para entrar en sistemas ajenos (sarcasmo OFF). Sabiendo que puede ser un Meterpreter, Ángela sabe cómo confirmarlo a través del comando strings de Volatility.

El comando strings necesita de la ejecución previa del comando strings.exe (ajeno a Volatility), que lo que hace es extraer las cadenas de texto de un fichero binario (como un volcado de memoria). Con este resultado Volatility es capaz de cruzar esas cadenas de texto y asociarlas a procesos, lo que nos viene de perlas a la hora de un análisis forense.

El proceso lleva su tiempo (10-15min en un ordenador moderno), pero tiene su recompensa. Ángela sabe que una sesión de Meterpreter hace uso de stdapi, por lo que puede hacer una búsqueda rápida y tener una confirmación del malware:

Si recordamos que el PID del rundll32.exe era 1100, tenemos suficientes pruebas como para condenar al equipo a un formateo sumario por compromiso total.

Ángela se pone en la piel del atacante: tengo una sesión de Meterpreter en el equipo, y además no necesito elevar privilegios porque ya soy administrador local ¿Qué haría? Obtener credenciales. Y si recordamos lo que vimos en la revisión de los logs, teníamos nada más y nada menos que una sesión iniciada de administrador de dominio. Un sudor frío recorre la espalda pensando en lo que podría hacer un atacante con acceso total al MINAF…

La búsqueda en las cadenas de texto del temido Mimikatz no ofrece resultados. Conociendo los comandos más habituales de Meterpreter, Ángela busca unas cadenas alternativas como “kiwi” (la nueva forma de llamar a Mimikatz) o “incognito” (el módulo de impersonación), encontrando un hit en el último:

No es una evidencia 100% fiable de que se ha ejecutado incognito, pero es lo mejor que se puede conseguir. Ángela sospecha que los atacantes han seguido este camino:

1. A través de la ejecución del enlace malicioso han logrado una sesión de Meterpreter en el sistema.
2. Los atacantes han comprobado que la cuenta en la que han aterrizado tiene privilegios de administrador, por lo que han lanzado Mimikatz y robado las credenciales del administrador de dominio.
3. Teniendo esas credenciales han usado el módulo incognito de Meterpreter para iniciar una sesión con privilegios de administrador de dominio.

Si damos un paso atrás al incidente y pensamos en cómo hemos detectado el incidente (el acceso a varias cuentas de correo de altos cargos a través del webmail) y el plazo de tiempo que han tenido los atacantes (unas pocas horas), la teoría más probable es que los atacantes se hayan hecho con los hashes de las contraseñas de dichos usuarios (ya sea a través de un ataque de DCSync o robando directamente el fichero NTDIS.dit de un controlador de dominio).

Con los hashes en la mano, un ataque vía Rainbow Tables o con Hashcat debería de proporcionarles a los atacantes las contraseñas en un plazo razonable de tiempo dependiendo de la fortaleza de las contraseñas (que Ángela sabe que no son 123456, pero que se podrían mejorar) y del hardware disponible (que si en AWS tienen semejantes bicharracos de 16 GPU no debería de ser un problema).

Otra opción sería ver si los atacantes han comprometido el servidor de correo Exchange, pero la cree menos factible ya que los atacantes llevan menos de 6h en el sistema (y además accedieron a la cuenta de pepe.contento nada más obtener sus credenciales vía Mimikatz).

De esta fase del análisis Ángela se queda con una foto más o menos borrosa (como suelen ser buena parte de estos análisis, nunca se tienen todos los datos) de lo sucedido y con un posible IOC: la IP 101.132.122.231, que puede volver a cruzarse con los logs tanto del cortafuegos como del proxy de navegación.

Le queda únicamente comprobar la vía de entrada del malware y ver si es capaz de capturar el malware original, algo que veremos en la siguiente entrada…

La entrada Agujas, pajares e imanes: Análisis forense de malware fileless (III) aparece primero en Security Art Work.

Paso 7: Correo

En la entrada anterior Salvador había destripado el malware y encontrado el C2, y Ángela había confirmado que era una sesión de Meterpreter, habiéndose hecho una idea de las posibles acciones realizadas por los atacantes.

Tan solo queda localizar el vector de entrada, que por el análisis de memoria sabíamos que era un correo electrónico malicioso. Es el momento perfecto para recuperar el equipo del usuario pepe.contento, entrar con un LiveUSB forense (como DEFT o SIFT) y recuperar el .ost del usuario del directorio C:\Users\pepe.contento\AppData\Local\Microsoft\Outlook.

Para leerlo en modo solo lectura la forma más cómoda es emplear Kernel OST Viewer, que permite abrir el fichero de correo entero (y con acceso a los metadatos). En 30 segundos Ángela ha encontrado lo que buscaba:

El enlace ya lo conocíamos, pero ahora tenemos el correo entero y comprobamos que en efecto es un spear-phishing de libro: remitente falsificado y conocido, mensaje dirigido al usuario con temática que incluso podría considerarse como interna y enlace malicioso diseñado a la perfección.

Si cogemos las caberas del mensaje podemos encontrar unos metadatos interesantes:

Received: from correo.mina.es (172.16.1.2) by correo.minaf.es (10.11.0.101)
with Microsoft SMTP Server id 14.3.408.0; Mon, 22 Oct 2018 22:37:54 +0200
Received: from [127.0.1.1] (unknown [101.132.122.231]) by correo.mina.es
(Postfix) with ESMTPS id 6A06E85AD6 for <pepe.contento@minaf.es>; Mon, 22 Oct 2018 22:38:09 +0200 (CEST)
Content-Type: multipart/mixed;
boundary=”===============7698037387482601352==”
MIME-Version: 1.0
From: =?utf-8?b?UlJISCBNSU5BRg==?= <rrhh@minaf.es>
To: <pepe.contento@minaf.es>
X-Priority:
X-MSMail-Priority:
Subject:=?utf-8?b?29uY3Vyc28gZmVsaWNpZGFkIHN1cHJlbWEgbmF2aWRhZGVzIDIwMTg=?=
Message-ID: <20181022203809.6A06E85AD6@correo.mina.es>
Date: Mon, 22 Oct 2018 22:38:09 +0200
Return-Path: rrhh@minaf.es
X-MS-Exchange-Organization-AuthSource: correo.minaf.es
X-MS-Exchange-Organization-AuthAs: Anonymous

[Nota: Debido a las múltiples pruebas realizadas en la preparación del taller, la fecha de envío del correo recibido es el 22 de Octubre, cuando debería de ser el 3 de Noviembre. Sed buenos con el autor… O:-) ]

Podemos comprobar que el mensaje ha falsificado la dirección de envío haciéndose pasar por RR.HH. del propio MINAF (Ángela lleva insistiendo más de un año en la necesidad de activar la verificación SPF en el servidor de correo, maldita sea), y que el correo ha sido enviado por correo.mina.es (y la IP es 101.132.122.231, la misma que encontramos en el análisis de memoria).

Al menos el análisis nos devuelve una nueva variedad de IOC que podemos cruzar con los logs de la pasarela de correo (no podemos usar el remitente rrhh@minaf.es porque al ser una dirección legítima del MINAF nos generaría una gran cantidad de falsos positivos):

• Asunto: “Concurso felicidad suprema navidades 2018” (ojo con las búsquedas porque algunos servidores las codifican, busca solo por palabras clave o hace uso de un decodificador online del RFC 20147).
• IP origen: 101.132.122.231
• Servidor origen: correo.minaf.es

La búsqueda nos da jugosos resultados: a lo largo del 3 de noviembre el correo malicioso ha sido enviado a 15 personas, todas ellas altos cargos del MINAF o su personal administrativo. Está claro que los atacantes sabían muy bien a dónde tenían que apuntar. Ángela envía un correo rápido avisando a los usuarios y se pone en contacto con Sistemas para que procedan a la búsqueda y borrado del mismo de los buzones afectados.

Pasado el momento de pánico, Ángela hace una pequeña pausa para reflexionar. Han pasado tan solo unas horas desde que se declaró el incidente, por lo que es posible que los atacantes sigan esperando a que más usuarios caigan en la trampa ¿Y si podemos hacernos con el mecanismo de entrega del malware?

Ángela decide correr un pequeño riesgo: en un ordenador limpio del MINAF instala Fiddler (para capturar todas las peticiones web) y pulsa sobre el enlace, obteniendo esta pantalla.

Esta vez ha habido suerte, así que sin dudarlo arrambla con todo el código y se junta con Salvador para analizarlo.

Paso 8: Análisis del malware web

Fiddler no deja ni una petición sin capturar, así que nos informa diligente que ha recogido 3 ficheros:

• felicidad.html
• felicidad.js
• felicidad.xsl

Salvador decide ser meticuloso y empezar por el código HTML, que sospecha que va a ser el precursor de todo el código malicioso. El examen deja entrever lo que está pasando:

Al parecer tenemos un Javascript incrustado y ofuscado que, sin detenernos a destriparlo, parece llamar a felicidad.js. Salvador decide saltar directamente al felicidad.js, que tiene un contenido escueto pero interesante:

Ninguno de los dos es experto en Javascript, pero la funcionalidad del código parece obvia: descárgate el fichero felicidad.xsl y ejecútalo. Saltando al tercer fichero encontramos el payload definitivo:

Salvador señala emocionado una parte del código: ¡Sharpshooter! ¡Nos han atizado con un Sharpshooter! Al parecer Sharpshooter es un generador de payload maliciosos con triple de ofuscación, evasión y queso, que los atacantes han empleado para ocultar en su interior el launcher de meterpreter. Y con muy buen tiento el parecer, porque al subirlo a MARIA casi ningún antivirus es capaz de detectarlo:

Con toda la información recabada en el análisis forense, Ángela tiene todo lo necesario para responder al incidente. El cierre del incidente, las lecciones aprendidas y una pequeña sorpresa en la última entrada…

La entrada Agujas, pajares e imanes: Análisis forense de malware fileless (IV) aparece primero en Security Art Work.

En el artículo anterior Ángela ya tenía gracias al análisis forense toda la información del ataque, así que le toca continuar con la respuesta al incidente en las fases de contención, erradicación y recuperación.

Respuesta al incidente

Con todas las respuestas importantes en la mano, Ángela puede hacer un esquema muy rápido del incidente:

1. Los atacantes envían un spear-phishing a Pepe Contento y otros altos cargos el 3 de noviembre sobre las 10.37h.
2. El usuario Pepe Contento abre el correo y pincha sobre el enlace el mismo día a las 11.05h, ejecutando el código malicioso entregado por Sharpshooter y comprometiendo su equipo con una sesión de Meterpreter.
3. Los atacantes verifican que tienen privilegios de administrador y obtienen las credenciales del equipo, encontrando el hash de un administrador de dominio (que tenía sesión iniciada en el equipo).
4. Los atacantes se hacen pasar por la cuenta de administrador de dominio y acceden a las contraseñas cifradas de varios altos cargos.
5. Estas contraseñas cifradas son rotas por los atacantes mediante un ataque de fuerza bruta, obteniendo las contraseñas en claro.
6. Los atacantes emplean esas credenciales para acceder a los webmail de diversos altos cargos entre las 11.30h y las 16.00h del mismo día.
7. A las 15.30h la usuaria maria.feliz detecta un comportamiento inusual de su cuenta de correo y lo comunica al CAU.
8. A las 15.45h el CAU corrobora el comportamiento extraño y avisa a Seguridad.
9. Seguridad accede a las 15.55h a los logs del correo y detecta los accesos anómalos.
10. Se declara incidente de seguridad a las 16.00h.

Bajo esta hipótesis la contención del incidente es bastante clara: el equipo de pepe.contento está apagado, por lo que no supone en estos momentos una amenaza. La contención inicial se reduce a forzar un cambio de contraseñas de todos los usuarios cuyas cuentas de correo han sido accedidas, así como bloquear en el cortafuegos todos los dominios pertenecientes a *.mina.es (para evitar futuros ataques por esta vía).

Siendo previsores, Ángela bloquea también las direcciones IP implicadas, creando además en el IDS reglas que permitan detectar el acceso tanto a las mismas como a cualquier dominio *.mina.es (para de esta forma detectar un futuro ataque aunque este no pueda progresar al estar bloqueado en el cortafuegos).

En este caso la contención y la erradicación se ejecutan en el mismo paso ya que Ángela ha esperado a hacer un “cierre perfecto” obteniendo toda la información necesaria de los atacantes (y también a que ha tenido suerte habiendo detectado el ataque en su fase inicial y evitando que los atacantes hubieran afianzado su posición).

Una erradicación en profundidad requiere de dos tareas adicionales: en primer lugar, Ángela está prácticamente segura que los atacantes han tenido acceso a un controlador de dominio, por lo que es posible que hayan robado TODOS los hashes de los usuarios. Por ello, y con pena de corazón (y de los usuarios), Ángela ordena forzar un cambio de contraseñas de los 5000 usuarios del MINAF.

La segunda tarea es mucho más compleja: los atacantes pueden haber empleado su acceso al controlador de dominio para dejar “regalos” como un Golden Ticket o una Skeleton Key. Ángela decide curarse en salud y ejecutar un doble reseteo de la cuenta KTBTGT (para invalidar el Golden Ticket) y reiniciar el controlador de dominio (para borrar la Skeleton Key de la memoria del servidor). Decide de forma adicional tenerlo bajo vigilancia durante al menos un par de semanas revisando todos los eventos y accesos para asegurarse de que está completamente limpio.

Le queda como tarea pendiente revisar el servidor de correo Microsoft Exchange, ya que cabe la posibilidad de que los atacantes lo hubieran comprometido con Ruler u otra herramienta similar. Ángela decide monitorizar los logs del Exchange en busca de accesos a las cuentas de los altos cargos desde direcciones IP fuera de España.

Lecciones aprendidas

El tiempo de detección (<6h) y de respuesta al incidente (< 10h) es inmejorable para un incidente de estas características. Sin embargo, todo incidente de seguridad tiene una fase de lecciones aprendidas en la que se analiza el incidente y se identifica qué podemos hacer mejor para evitar que se produzca un incidente similar, así como mejorar nuestra capacidad de respuesta a incidentes.

En el caso del incidente, Ángela y Salvador se reúnen con el CIO del MINAF y le proponen las siguientes acciones de mejora:

• Mejorar la concienciación: Aunque es cierto que el incidente ha sido detectado con rapidez gracias a una usuaria, se ha producido por culpa de las acciones de otro usuario. Identificar a los usuarios que necesitan un refuerzo de concienciación en seguridad y proporcionárselo debería de ser prioritario.
• Mejorar la comunicación entre áreas: El CAU no tendría que haber dado privilegios de administrador local a los altos cargos sin la autorización de Seguridad de la Información. Es necesario establecer procedimientos para que los cambios críticos tengan que ser aprobados (o como mínimo consultados) con las áreas directamente afectadas.
• No usar cuentas de administrador de dominio para la gestión de equipos de usuario: Es una batalla frecuente en las grandes organizaciones, pero se debe establecer una estructura en capas (como indica Microsoft en su documento de medidas contra ataques de movimiento lateral) en la que los grupos con privilegios más sensibles no accedan a equipos con menos privilegios para prevenir de esta forma el robo de hashes.
• Cuentas de usuario sin privilegios de administrador: Los usuarios no deberían de tener privilegios de administrador en sus cuentas de forma habitual, salvo contadas ocasiones y siempre de forma totalmente justificada. De esta forma se fuerza a un atacante a escalar privilegios, algo que puede bloquear su ataque o facilitar su detección.
• Contraseñas robustas: Unas contraseñas robustas (12+ caracteres, mezclando mayúsculas, minúsculas, números y símbolos de puntuación, sin usar palabras de diccionario) no son la panacea, pero aumentan el coste del ataque para los atacantes (bien en tiempo o en dinero).
• Activar SPF: Una forma muy sencilla de verificar el origen de un correo es activar la verificación SPF (Sender Policy Framework), un protocolo de seguridad que se monta encima de SMTP y que nos permite detectar correos con el origen falsificado (en este caso bloqueando el correo con el origen rrhh@minaf.es.
• Desplegar 2FA en el webmail: Todos los accesos externos del MINAF deberían estar protegidos por un segundo factor de autenticación, de tal forma que aunque un atacante se hiciera con las credenciales no pudiera acceder al correo.

Bonus Extra 1: Sysmon

Imaginemos que Ángela hubiera podido desplegar algún tipo de herramienta de monitorización del puesto de trabajo (endpoint). En nuestro caso ponemos como ejemplo Sysmon, un software de Microsoft que permite monitorizar una amplia gama de la actividad de un equipo (creación de procesos, conexiones, modificación del registro, etc…).

Sysmon guarda toda la información de su operación en un log de eventos: Sysmon/Operational, por lo que se puede consultar la información recogida con el Visor de Eventos.

Si el equipo de pepe.contento hubiera tenido Sysmon desplegado, Ángela lo habría tenido muy fácil para detectar la intrusión. Aquí tenemos la conexión inicial de wscript.exe ejecutando el contenido del enlace malicioso:

Aquí la creación en el registro de Windows del servicio malicioso con nombre aleatorio:

Y aquí el establecimiento de la clave de registro para la persistencia de los atacantes:

Como se puede observar, Sysmon permite detectar diversas fases de la ejecución del malware. Si además, centralizamos la salida de Sysmon en un servidor externo, tenemos un potencial tremendo para detectar ataques dirigidos. Y si además, disponemos de analizadores especializados para automatizar todo el proceso (como en la herramienta CARMEN desarrollada entre el CCN-CERT y S2 Grupo), tenemos sin duda una herramienta muy potente para complicarle la vida a los atacantes.

Bonus Extra 2: ¿Y si los malos fueran muy listos?

Este incidente ha tenido una resolución feliz (y sobre todo, rápida). Pero imaginamos otro escenario en el que los atacantes hubieran sido especialmente competentes, tomando diversas contramedidas para dificultar su detección. Algunas acciones que podrían haber tomado serían:

• Reiniciar el equipo de pepe.contento: De esta forma se habría perdido por completo el contenido de la RAM, por lo que no podríamos saber fácilmente ni la vía de entrada ni las acciones realizadas por el atacante.
• No dejar persistencia en memoria: No lo podríamos localizar en el registro ni obtener información sobre el malware empleado por los atacantes.
• Smash & Grab: Si los atacantes solo quisieran las credenciales, podrían hacer el ataque al DC (DCSync/NTDIS.dit) y reiniciar el equipo de pepe.contento sin dejar persistencia. El único rastro es la (escasa) navegación web por el dominio malicioso.
• Los atacantes, una vez conseguidos sus objetivos, tiran el servidor web de sharepoint.mina.es: no tendríamos el contenido de los felicidad* y no podríamos saber qué malware ha sido empleado para comprometer el equipo (tan solo los accesos en los logs del proxy de navegación).
• Los atacantes borran el correo del cliente: no sabríamos el vector de entrada del ataque (salvo algunos rastros en los logs de navegación del correo).

Sin embargo, hay que romper con esa creencia que tienen muchos defensores en la que “los atacantes son siempre buenísimos, tienen 0-days para dar y regalar, malware invisible y siempre van dos pasos por delante de nosotros”. En muchos casos los atacantes son gente con un nivel técnico similar al de los defensores, con sus herramientas, conocimiento, objetivos y necesidades. Como el autor leyó hace tiempo en Twitter, “los atacantes también tienen jefes y presupuestos”). En definitiva, tenemos que hacer nuestro este mantra:

“Los atacantes no son perfectos”

Esta afirmación implica que a veces serán torpes, cometerán errores o harán algo que nos permitirá detectarlos. Se dice en seguridad que “los defensores tienen que tapar todos los agujeros, mientras que los atacantes únicamente necesitan encontrar uno”. En respuesta ante incidentes, el dicho se invierte: “los atacantes tienen que hacerlo todo perfecto, porque con que cometan un único error podemos detectarlos”.

La entrada Agujas, pajares e imanes: Análisis forense de malware fileless (V) aparece primero en Security Art Work.

Aparte de algunos objetivos más concretos, como la compañía Westinghouse Electric Company’s -con negocios en tecnología nuclear- o routers domésticos que puedan ser comprometidos para orquestar un ataque distribuido contra el objetivo real, la información publicada en 2018 ha sacado a la luz cinco grandes objetivos del GRU, consistentes con los intereses del Servicio y por consiguiente con los de la Federación Rusa; son los expuestos en este punto.

Llama la atención que en la mayor parte de estos objetivos -salvo quizás Ucrania y sus infraestructuras- el GRU tiene, siempre presuntamente, un interés relacionado más con la confrontación de información psicológica a la que hemos hecho referencia que con un ataque puramente técnico; dicho de otra forma, es poco probable que el GRU ataque a objetivos como los investigadores del uso de Novichok o del derribo del MH17, que veremos a continuación, con la intención de alterar tecnológicamente los resultados de estas investigaciones… es más probable que el objetivo real fuera obtener información por un lado para conocer de primera mano el estado en cada momento y por otro, igualmente importante, para poder obtener datos que permitiera al Servicio el inicio de campañas de desinformación contra estos organismos investigadores, de manera que de cara a la sociedad perdieran credibilidad en sus afirmaciones, beneficiando así los intereses de la Federación Rusa.

Se resumen en la tabla siguiente las operaciones y acusaciones relacionadas con los objetivos del GRU que se han hecho públicos de manera oficial en 2018:

Elecciones USA 2016

El objetivo con el que se iniciaron las acusaciones públicas contra el Servicio es la injerencia en las elecciones estadounidenses del año 2016. Como hemos visto, en julio el fiscal Mueller lanza una dura y detallada acusación contra el GRU en relación a sus actividades de injerencia en dichas elecciones, en las que supuestamente los intereses rusos pasaban por el triunfo de Donald Trump frente a su rival, para lo que también supuestamente robaron información de sistemas relacionados con el Partido Demócrata y la utilizaron para desprestigiar a Hillary Clinton, en lo que parece una clara operación de influencia que por supuesto el Kremlin ha negado.

Si los rusos efectivamente actuaron para beneficiar a un candidato, o si ese candidato estaba al tanto de estas supuestas actividades, ya se comprobará; Mueller, o la comunidad de inteligencia estadounidense -no sólo en julio sino en otros momentos- han aportado datos e informes que parecen confirmar al menos la primera de las hipótesis, pero como casi todo en esta vida, esto se puede falsear. ¿Por qué puede interesarle al Kremlin la victoria de Donald Trump? Por supuesto tengo mis hipótesis, ligadas a la estabilidad de lo que los rusos denominan “Occidente”, pero este tema excede la temática del presente trabajo…

Novichok

El uso del Novichok, un agente nervioso de grado militar, en el ataque contra los Skripal y la investigación posterior por parte de diferentes organismos ha sido otro de los objetivos de interés para el GRU que ha salido a la luz en 2018; los operativos identificados en La Haya realizaban -presuntamente- una operación close access contra la OPCW, que entre otros temas investiga el ataque con Novichok en territorio británico. También son acusados de tener entre sus objetivos al Laboratorio Spiez, el Instituto Federal Suizo para la Protección NBQ (nuclear, biológica y química) que es parte de la Oficina Federal para la Protección Civil; este laboratorio es el que confirmó que el producto usado contra los Skripal era efectivamente Novichok, e igualmente al UK Defense and Science Technology Laboratory (DSTL), que también trabajaba en la investigación por el uso del agente nervioso.

El interés del GRU por los actores que han investigado el asunto del Novichok es completamente normal; se ha acusado a dos de sus agentes del uso de esta sustancia en una operación en territorio extranjero, por lo que es lógico que el Servicio tenga interés en conocer estas investigaciones antes que los demás -no decimos alterarlas, decimos conocer- e incluso ejercer alguna operación de desinformación contra los actores que investigan estos temas. Y si de paso esos actores investigan también otros temas de interés para el GRU, como lo hace la OPCW con el uso de armas químicas en Siria (del que Rusia acusa a los rebeldes y Occidente al régimen de Assad), pues mejor que mejor: dos pájaros de un tiro.

Dopaje en el deporte

En 2016 el Comité Olímpico Internacional acusó a Rusia de un dopaje sistemático de sus atletas, respaldado por el propio Kremlin, en las Olimpiadas de Sochi 2014 entre otras competiciones, motivo por el cual Rusia estuvo a punto de ser excluida de las Olimpiadas de Río de Janeiro 2016; esto, que podría parecer ajeno a muchos ámbitos de la inteligencia, suponía un golpe a la imagen de Rusia como potencia mundial, ya que los Juegos Olímpicos pueden usarse como proyección hacia el mundo y como una exhibición de fuerza… lo que los analistas denominan un softpower. Efectivamente, un escaparate como los Juegos Olímpicos puede considerarse así, y no debemos infravalorar este tipo de “poder blando” en la estrategia e imagen rusas; de hecho, algunos analistas ([1]) identifican la escasa preocupación del Kremlin por el descubrimiento de sus operaciones también como un softpower: la demostración de las capacidades rusas como potencia mundial para interferir unas elecciones u operar en casi cualquier parte del mundo. Por supuesto, es peor no haber cumplido la misión, como en el caso de los Skripal o de La Haya, que haber sido descubierto.

Sea como sea, este objetivo del GRU es quizás el más curioso para diferentes analistas (no así las actuaciones en Ucrania o la investigación del ataque al MH17). Llama la atención que el GRU esté implicado en asuntos relativos al dopaje, ya que a priori temas relacionados con el softpower del deporte estarían más cercanos al ámbito de actuación del FSB (o incluso del SVR) que del GRU, que recordemos es un servicio de inteligencia militar. Sin embargo, aunque parezca raro, no es la primera vez que el el GRU trabaja en temas que a priori corresponderían a otros servicios de la Federación Rusa: por ejemplo, en 2014 fue expulsado de Francia el Coronel del GRU Viktor ILYUSHIN, acusado de buscar información  personal comprometida (el famoso kompromat) del Presidente Holland, en una operación que, ligada al ámbito político, correspondería sobre el papel a otros servicios rusos. Pero de la misma forma, el FSB ha operado en el campo del SVR o del GRU cuando se ha expandido por el Báltico o Europa del Norte ([2])… un ejemplo más de la competitividad de los servicios rusos.

MH17

En julio de 2014 un avión de pasajeros de la línea Malaysia Airlines (MH17) que cubría la ruta Ámsterdam – Kuala Lumpur con casi 300 personas a bordo fue derribado mientras sobrevolaba el espacio aéreo ucraniano. De manera inmediata, las autoridades ucranianas y rusas se acusaron mutuamente del ataque, e investigadores holandeses, entre otros, comenzaron el análisis para determinar causas y origen del ataque. Tiempo después, en octubre de 2015, el Dutch Safety Board emitió un informe confirmando que el avión fue derribado por un misil de la serie Buk 9M38, de origen ruso; en dicho informe no se especificaba quién había lanzado el misil, pero sí el área aproximada desde la que se había hecho: un área controlada con los rebeldes separatistas pro rusos. Tiempo después, ya en mayo de 2018, el equipo de investigación conjunto de los gobiernos holandés y australiano acusó oficialmente al gobierno ruso de responsabilidad en el ataque, con el inmediato apoyo de los aliados habituales; por supuesto, Rusia siempre ha negado los hechos y ha acusado de montaje a las investigaciones, defendiendo su falta de transparencia y considerándolas un montaje político.

En 2018 el gobierno holandés ha acusado al GRU de ataque a los investigadores del derribo del MH17, tanto en Holanda como en Malasia, a partir del material incautado a los miembros del Servicio descubiertos en La Haya y públicamente ha hablado de manipulación y operaciones de influencia en relación a estos objetivos. Por su parte, investigaciones privadas como las de Bellingcat también han analizado la relación de Rusia con el derribo del MH7, desmontando -presuntamente- hipótesis como la de un vuelo de Aeroflot como objetivo real del ataque o identificando como personas de interés a miembros del ejército ruso en la zona. En cualquier caso, el interés del Servicio por estas investigaciones es algo que no sorprende a nadie, tanto por la relación de Rusia con el ataque como por la zona de interés en la que se produjo el derribo del avión comercial.

Ucrania

El conflicto Ucrania-Rusia, que se viene prolongando hasta la actualidad y no parece poderse resolver en breve, ha sido objeto también de los intereses del GRU. El NCSC británico acusó al Servicio ([3]) de ataques destructivos contra infraestructuras críticas ucranianas (metro de Kiev, aeropuerto de Odessa…) con BadRabbit, el supuesto ransomware que inutilizó sistemas de estas infraestructuras, e igualmente responsabilizó al GRU de los ataques contra Ucrania en junio de 2017, en los que NotPetya impactó en los sectores financiero, energético y gubernamental de este país.

De las actividades del GRU en Ucrania es necesario destacar que son acciones CNA, de ataque puro (las cuatro D: disrupt, deny, degrade, destroy), no de robo y explotación de información (CNE) a la que estamos más acostumbrados con actores estado o con grupos APT; de nuevo, insistimos en que el GRU en un servicio de inteligencia militar, y por este segundo apellido la ejecución de operaciones destructivas no son de extrañar entre sus capacidades y atribuciones.

Referencias

[1] Mark Galeotti. Heroes of the Fatherland: : Killing Here, Hacking There. The Moscow Times. Diciembre, 2018. https://themoscowtimes.com/articles/heroes-of-the-fatherland-killing-here-hacking-there-63901

[2] Mark Galeotti. Putin’s Hydra: Inside Russia’s Intelligence Services. European Council on Foreing Relations. Mayo, 2016.

[3] NCSC. Reckless campaign of cyber attacks by Russian military intelligence service exposed. Octubre 2018. https://www.ncsc.gov.uk/news/reckless-campaign-cyber-attacks-russian-military-intelligence-service-exposed

La entrada (Ciber) GRU (X): objetivos aparece primero en Security Art Work.

En el artículo de hoy os hablaremos de uno de los protocolos de moda, MQTT y cual es su impacto, en cuanto a ciberseguridad se refiere, en España. MQTT es ampliamente usado en el ámbito industrial, domótica y, en general, en todo lo relacionado con IoT.

MQTT es un protocolo de mensajes muy simple y ligero que se basa en un modelo publisher/subscriber, también conocido como productor/consumidor. Por una parte tendremos los publishers, que serán aquellos encargados de generar los mensajes a enviar. Siguiendo el flujo de las comunicaciones, encontraríamos el intermediario (broker), que será el encargado de distribuir los mensajes a los consumidores o subscribers. MQTT es un estándar ideado para las comunicaciones M2M (Machine to Machine) en las cuales varios dispositivos comparten información, ya sea a través de un medio cableado o inalámbrico.

Nos faltaría conocer cuál es el proceso por el cual pueden los nodos publicar o suscribirse a información. Debemos tener en cuenta que este modelo está ideado para dispositivos de poca potencia y con consumos reducidos, como pueden ser muchas redes de sensores, donde se necesita que los dispositivos emitan o reciban información de manera periódica permaneciendo el resto del tiempo en un estado de consumo mínimo. Para ello, el broker permanecerá activo constantemente a la espera de acciones por parte de los dispositivos situados en los extremos. Este será, típicamente, un componente de mayor potencia que realizará tareas para mantener el estado del sistema. Mientras que los extremos, publishers y subscribers, se limitarán a actuar de manera periódica.

Ejemplo de comunicación mediante MQTT

El último aspecto fundamental para comprender MQTT son los topics o temas. Éstos son el mecanismo por el cual se clasifica la información que se maneja. Cada publisher que quiere emitir determinada información lo asociará a un topic que almacenará el broker, y que podrá ser leído por los subscribers que accedan a ese topic en particular.

Por lo tanto, con los fundamentos básicos de MQTT establecidos, podemos fijarnos en el abanico de aplicaciones dónde podemos encontrarlo. Por ejemplo, si accedemos a la URL http://ny-power.org/mqtt, encontraremos un sitio web donde se reciben datos sobre el consumo energético de la ciudad de Nueva York. Podríamos acceder a estos datos a través de un suscriptor de MQTT, para lo cual podemos utilizar el siguiente repositorio de Github https://github.com/eclipse/mosquitto. Compilando el código del directorio client obtendremos tanto un publisher como un subscriber, que es tan sencillo como tener las dependencias necesarias para hacer make dentro de éste. Ejecutando el comando que aparece en el sitio web empezaríamos a recibir datos con los que se puede jugar.

Pero en vez de pensar en un servicio que es público, como el del ejemplo anterior, pensemos en un caso en que se domotiza un hogar y sus propietarios tienen acceso remoto a información propia del mismo, como la temperatura de la vivienda, las luces que se encuentran encendidas, el estado de las puertas o de las persianas, etc. En este caso no creemos que el deseo de los propietarios sea que esa información pueda ser accedida públicamente, y menos que pueda ser modificada y que desencadenara una acción de manera inesperada.

Obviamente, cuando se diseñó MQTT se tuvieron todos estos estos problemas presentes, no olvidemos que se trata de un estándar ISO, y se establecieron mecanismos de autenticación basados en usuarios y contraseñas, así como el cifrado de las comunicaciones mediante SSL. Sin embargo, los usuarios finales somos muy cómodos y queremos que todo sea plug-and-play sin que nos caliente la cabeza el nuevo cacharrito que nos hemos comprado y que nos va a permitir prepararnos las tostadas mientras nos lavamos la cara recién levantados…

Para llevar a cabo nuestro estudio nos planteamos descubrir todos los dispositivos en Internet que utilizaran este protocolo. Para ello, la opción más cómoda es Shodan y nos permitió observar que, a fecha de 5 de enero, hay un total de 70.032 dispositivos MQTT a nivel mundial.

Número de dispositivos por país

Entre estos 7 primeros países se supera el 50% de los dispositivos totales calculados previamente. Además podemos ver como el número de dispositivos es más abundante en los países orientales. España queda en 12º lugar con un total de 1.372 dispositivos en los que nos centraremos más adelante. Otro dato de interés es el software utilizado para soportar esta tecnología:

• un total de 43.063 dispositivos utilizando como plataforma MQTT, software que toma el mismo nombre que el protocolo que implementa y que es distribuido por la organización encargada del desarrollo del protocolo y que podemos descargar desde http://www.mqtt.org/software
• y un total de 26748 dispositivos que utilizan mosquitto, el cual se trata de una implementación open source de las versiones 3.1 y 3.1.1 del software anterior.

Un dato curioso es que mientras que a nivel global el software de MQTT parece estar más presente que mosquitto, en España la cosa cambia drásticamente encontrando 1.018 dispositivos que usan mosquitto (75% de dispositivos) frente a 353 utilizan MQTT.

DISPOSITIVOS ACCESIBLES DESDE INTERNET SIN AUTENTICACIÓN

Nos encontramos con que existen una serie de códigos de respuesta del protocolo que identifican cuando los dispositivos no implementan medidas de autenticación. El código 0 significa que el dispositivo se encuentra accesible, mientras que los códigos 4 y 5 significan que se requiere usuario y contraseña, y que el acceso no está autorizado, respectivamente.

Haciendo uso de los datos obtenidos de Shodan y un script muy simple para extraer aquellos valores que nos interesan, obtenemos rápidamente el registro de información que nos interesa. El resultado es que la cifra de dispositivos abiertos es de 1.122, un 81% de los dispositivos existentes en España.

SOFTWARE INSEGURO

Otro dato que puede resultar de interés es conocer la versión de software que utilizan los dispositivos.

Diferentes versiones del software y su proporción en España

Como se observa en el gráfico anterior, alrededor del 60% de los dispositivos utilizan la versión 1.4.8 de mosquitto. Si buscamos en el repositorio de Github, podemos ver que la siguiente versión a ésta tiene la fecha de 2 de junio de 2016. Por lo tanto, podemos observar que la gran mayoría de los dispositivos no son actualizados, con los riesgos que esto conlleva. El siguiente enlace recopila las vulnerabilidades que han sido encontradas en este software https://mosquitto.org/security/. También se tiene que apuntar que la primera vulnerabilidad no se soluciona hasta la versión 1.4.11; por lo tanto la mayoría de dispositivos en España serían vulnerables.

DATOS EXPUESTOS DIRECTAMENTE A INTERNET

Lo último que nos gustaría mostraros de los datos obtenidos de Shodan son algunos de los topics que podemos encontrar en las direcciones IP que hemos listado anteriormente.

Extracto de topics públicos en Internet

Recopilando el total de topics publicados por el conjunto de dispositivos suman 5.341, todos ellos pertenecientes a dispositivos españoles. Entre ellos podemos observar diferentes marcas tanto de dispositivos como del software que utilizan (llaman la atención alarmas, puertas, luces, termostatos, etc). ¿Se podrían modificar algunos de éstos valores? Es una pregunta que dejamos en el aire.

Debemos ser conscientes de aquello que metemos en nuestras vidas y en nuestros hogares. Muchos de estos dispositivos que utilizamos vienen con configuraciones por defecto y sus fabricantes, en ocasiones, prefieren adornar sus funcionalidades a proveerlos de medidas de seguridad eficaces.

La entrada El protocolo MQTT: impacto en España aparece primero en Security Art Work.

Las informaciones que han salido a la luz en los últimos meses, en especial la acusación de Mueller, han identificado diferentes tácticas y técnicas del GRU, algunas de ellas conocidas previamente -y en muchos casos ligadas a APT28- y otras que, aunque todos nos podíamos imaginar, nadie había confirmado con anterioridad. Se muestran resumidas en la siguiente tabla dichas TTP, basadas en una adaptación de las tácticas y técnicas que publica MITRE en su framework ATT&CK:

Como hemos adelantado, la mayor parte de las técnicas anteriores habían sido atribuidas previamente al GRU, en concreto a APT28 (un buen detalle puede obtenerse en [1]), y entran dentro de las consideradas “normales” en cualquier operación CNE; no obstante, de todas ellas hay una que oficialmente NO se asociaba con este grupo -tampoco aparece en la acusación de Mueller-, y por tanto con el GRU, hasta el momento: las operaciones close access, que si bien se vienen ejecutando desde hace años por los servicios de inteligencia no se habían documentado en el caso de APT28. En 2018 se ha confirmado que el GRU aborda operaciones de proximidad: de los cuatro miembros del Servicio detenidos en Holanda dos pertenecen a la Unidad 26165, pero los otros dos no. Uno de ellos, MININ, se identifica como miembro de la Unidad 22177: el “Conservatorio”, la Academia Militar del Ministerio de Defensa ruso donde se forman los oficiales de inteligencia. De esta forma, y siempre aparentemente, los dos oficiales de la Unidad 26165 se encargarían de los aspectos tecnológicos de la operación, mientras MININ y SOTNIKOV de los aspectos HUMINT y de apoyo. Estas operaciones close access del GRU son similares a las que ejecuta el Special Collection Service estadounidense: operativos de la CIA y de la NSA trabajando conjuntamente para implantar en sitios de difícil acceso.

¿Por qué el GRU decide abordar una operación de este tipo para comprometer a la Organización para la Prohibición de las Armas Químicas? Quizás la OPCW fuera un objetivo duro, difícil de comprometer con técnicas puramente ciber (spear phishing, watering hole…) y eso motivó que el Servicio desplazara a cuatro personas a Holanda para la operación. O quizás aprovecharan una inspección de seguridad de la embajada rusa en Holanda, muy cercana a la sede principal de la OPCW como muestra la imagen, para intentar comprometer a esta Organización. O simplemente los cuatro miembros del GRU estaban, en realidad, haciendo una inspección de seguridad, coartada oficial pero hipótesis menos probable si atendemos al análisis de los dispositivos incautados… En cualquier caso, las pobres medidas de seguridad operacional dan a entender que los agentes del GRU en ningún momento consideraron la operación como de riesgo ni imaginaron que podrían ser detenidos y expulsados, como finalmente pasó.

También resultan interesantes para los analistas las actividades CNA puras contra Ucrania; si nos ceñimos a las tácticas expuestas por MITRE deberíamos englobar estas acciones en el ámbito de la táctica “ejecución”, también explotando vulnerabilidades en los sistemas comprometidos pero no para persistir, elevar privilegios o exfiltrar información, sino para destruir los objetivos. Pero como las relaciones que expone MITRE no son completas (es, como casi todo, un excelente trabajo en proceso continuo), para ser técnicamente correctos estaríamos hablando de una táctica nueva, por ejemplo “destrucción”: el GRU -o APT28, como prefiramos- ejecuta acciones destructivas ciegas, que no requieren persistencia ni mando y control y que por tanto no entran en las tácticas “estándar” de las amenazas orientadas al robo de información (ámbito CNE); y las técnicas del GRU para abordar esta destrucción pasan por el borrado o el cifrado no reversibles de ficheros. Recordemos de nuevo que el GRU es un servicio de inteligencia militar, por lo que no es de extrañar la ejecución de operaciones destructivas puras, independientes del robo de información, contra un objetivo.

Referencias

[1] Paul Pols. Modeling Fancy Bear Cyber Attacks. Fox IT Cyber Security Academy. Diciembre, 2017.

La entrada (Ciber) GRU (XI): TTP aparece primero en Security Art Work.

El artículo 42 de la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos, estipula la necesidad de redacción de un Esquema Nacional de Seguridad que establezca la política de seguridad en la utilización de medios electrónicos.

Dicho esquema tardó tres años en llegar en forma de Real Decreto (RD 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica) y es de imperativo cumplimiento para todas las Administraciones Públicas, entre otros. En la disposición transitoria de dicho decreto se articula un mecanismo escalonado para la adecuación a lo previsto en el Esquema Nacional de Seguridad de manera que los sistemas de las administraciones han de estar adecuados a este Esquema en unos plazos en ningún caso superiores a 48 meses desde la entrada en vigor del mismo. El plazo de adecuación venció el 30 de enero de 2014.

Sin embargo, el legislador, consciente de que los plazos no se habían cumplido por parte de las Administraciones Locales, decidió prorrogar su aplicación dos años más mediante el Real Decreto 951/2015, de 23 de octubre. Tras este decreto, el ENS debería estar aplicado en la totalidad de las administraciones a fecha 5 de noviembre de 2017.

Nuestro compañero Adrián Capdevila ya informó sobre este incumplimiento en el año 2015 en este post, y parece que no ha mejorado mucho desde entonces.

¿Cuál es la realidad actual? A día de hoy, tan solo hay certificados 3 ayuntamientos de un total de 8.125 (lo que representa un 0,04%) y 2 universidades públicas de un total de 52 (un 3,85%).

¿Dónde está el problema? Principalmente, en el desconocimiento de las administraciones de esta obligación, por mucho que se empeñen las Federaciones de Municipios en hacer ver la necesidad de cumplir la ley, y se pongan en marcha herramientas de ayuda. Y complementariamente, por los funcionarios “más veteranos” que en ocasiones se niegan a meterse en este jardín por aquello de lo tecnológico, sumado a que los representantes políticos ven absurdo asignar presupuesto a algo que “no se ve”. Pensar que es un problema presupuestario tiene poco recorrido, puesto que la mayoría de administraciones cuentan con medios materiales y personales para llevarlo a cabo sin problema (de los 62 municipios con más de 100.000 habitantes, sólo hay uno adaptado al Esquema, lo que representa el 1,61%).

Queda mucho por hacer desde todas las Administraciones Públicas, y la seguridad de los sistemas de información que están al servicio de los ciudadanos no son asuntos menores.

Puedes leer más sobre el ENS aquí, aquí y aquí.

La entrada ¿Qué pasa con el ENS? aparece primero en Security Art Work.

Los miembros del GRU expulsados de Holanda aplicaban medidas básicas de OPSEC, como llevarse ellos mismos la basura de la habitación del hotel; no obstante su detención ha puesto de manifiesto la falta de otras medidas de seguridad, igualmente básicas, que sin duda habrán dado mucho que hablar en el Servicio. Quizás las operaciones de proximidad -en Holanda al menos- no eran consideradas como de riesgo por el GRU, quizás son fallos humanos por incumplimiento de normativa… quién sabe. El hecho cierto es que esta OPSEC pobre ha sacado a la luz información sobre identidades, objetivos, TTP… del Servicio que nos han permitido conocerlo un poco mejor durante 2018 y que, de haber actuado de otra forma, estas evidencias no lo serían tanto.

Cuando hablamos de OPSEC, más allá de modelos y metodologías formales, hablamos siempre de las tres C [1]: cover, concealment, compartmentation. La cobertura de una operación debe permitir justificar dónde estás (estado) y qué estás haciendo (acción), la ocultación debe permitir ocultar actividades o identidades relacionadas con la operación y, por último, la compartimentación, como línea de defensa final, debe minimizar el impacto en caso de que las cosas vayan mal, no afectando a otras personas, operaciones, etc.

En el caso de los agentes identificados en Holanda, su cobertura era, como hemos dicho, una inspección de seguridad en la embajada rusa en Holanda, cercana a la sede de la OPCW; esto podría justificar que estaban en las proximidades de dicha sede, pero a partir de los dispositivos incautados difícilmente justificaría la acción, lo que estaban haciendo concretamente en esas proximidades… pero un apunte: ¿estas inspecciones de seguridad corresponden a un servicio militar? ¿No serían responsabilidad del FSO o, en todo caso del FSB? Curioso… En cualquier caso, si la cobertura era débil, la ocultación lo es más, cuando tenemos a cuatro miembros del Servicio viajando con identidades reales, pasaporte diplomático (con números secuenciales)… a una operación, y guardando entre sus pertenencias no sólo dispositivos electrónicos, sino también algo tan mundano como un ticket de taxi desde la sede de la Unidad hasta el aeropuerto, por poner un ejemplo -ticket confirmado como verdadero por la empresa de taxis correspondiente, de Moscú-. Esta ausencia de medidas de seguridad ha motivado que diferentes analistas, a partir de fuentes públicas, puedan obtener datos personales de los agentes, como sus perfiles en redes sociales o los clubes de fútbol en los que juegan; por ejemplo, se llega hasta el perfil de Aleksei SERGEYEVICH MORENETS en el portal mylove.ru, un sitio de citas ruso, en el que aparece el miembro de la Unidad 26165 con una foto tomada en Moscú, a pocos metros de la sede del Servicio.

Perfil de Aleksei SERGEYEVICH MORENETS en mylove.ru (Fuente: Daily Mail)

Si las medidas de cobertura y ocultación de los agentes detenidos en Holanda son pobres, las de compartimentación lo son quizás más; en los equipos incautados se muestran no sólo datos de la operación que estaban desarrollando, sino datos de otras operaciones que poco o nada tenían que ver con ésta. Desde una foto tomada en las Olimpiadas de Rio de 2016 -hecho que confirma que MORENETS estuvo allí, no sabemos si por motivos personales o laborales, hasta históricos de navegación y búsqueda de posibles objetivos ajenos a la OPCW o conexión a redes WiFi en hoteles de Kuala Lumpur, supuestamente al hilo de la investigación de Malasia por el caso del MH17; aunque uno de los agentes intentó destruir un teléfono móvil al ser sorprendidos, según afirma el gobierno holandés, el equipamiento electrónico ha mostrado trazas de actividades muy interesantes de los miembros del Servicio. Que estas actividades estén relacionadas con las operaciones del GRU -o no- es algo que no sabemos, pero en cualquier caso, sean trazas y datos personales o profesionales, NO deberían haber estado en esos dispositivos de ninguna forma.

¿Por qué se pueden producir estos errores? Como se suele decir, los atacantes también presupuestos, jefes, plazos… en su trabajo, y todos cometemos errores. Aunque mi opinión personal es que una operación, por simple o poco arriesgada que sea a priori, requiere de unas medidas OPSEC mínimas, desconozco por qué motivo (técnico, político, presupuestario…) en este caso no se aplicaron. No obstante, es necesario destacar que fallos aparentemente graves de OPSEC no son exclusivos del GRU; el FSB no se queda atrás en errores históricos en cuanto a medidas de seguridad operacional, como lo demuestran en el ámbito ciber supuestos documentos del CSEC canadiense filtrados por Snowden ([2]) en los que se explica cómo los operadores de Turla (¿ligado al FSB?) utilizan los entornos operativos de una campaña para un uso personal (consulta de correo y redes sociales, navegación…). También en un ámbito físico miembros del FSB han cometido errores muy graves, como cuando en 2016 una nueva promoción de agentes celebraron el fin de curso fotografiándose en Moscú y dando un paseo en Mercedes todoterreno por la capital rusa; en las redes sociales aún pueden encontrase imágenes del evento. El FSB premió esta actitud destinándolos a las zonas de Chukotka y Kamchatka, en el extremo oriental de Rusia, a más de ocho horas de vuelo de Moscú. Quien esté libre de pecado…

Referencias

[1] TheGrugq. OPSEC in the age of the egotistical giraffe. HITBSecConf, 2014.

[2] Canada CSEC. Hackers are humans too. Cyber leads to CI leads.

La entrada (Ciber) GRU (XII): OPSEC aparece primero en Security Art Work.

NOTA: Ante todo destacar que esta publicación consiste en una recopilación de artículos que he usado (y alguna cosa con la que me he tenido que pegar). El contenido pertenece a otras personas y los enlaces a los originales se encuentran en esta misma publicación.

En lo que a la auditoría de aplicaciones para móviles Android se refiere, nunca me he metido demasiado, principalmente por falta de tiempo y porque al final aunque se pueda ver el código, cada desarrollador hace las cosas a su manera (las buenas manías de cada developer).

Hace un tiempo me encontré un caso de un cliente en el que, por necesidad (por co****s), había que hacer uso de una aplicación para analizar todo el flujo de trabajo (workflow para angloparlantes) de la solución diseñada. El problema de esto es que, pese a que la aplicación era accesible y su código (versión Android) también, se hacía pesadísimo el análisis de las funcionalidades, además de que prácticamente todas las interesantes estaban relacionadas con peticiones a diversos servidores.

Lo normal habría sido usar un proxy para poder ver las comunicaciones pero el SSLpinning es algo que ya está prácticamente en todas las aplicaciones de los markets y dado que Android desde su versión 6 hace caso omiso de los certificados de usuario pues…

En esta situación me topé con que tenía que bypassear (aka evadir/evitar para los hispanohablantes) el mecanismo de seguridad.
Mi primera intención fue modificar el código de la aplicación. De este modo, identifiqué que se hacía uso de OkHTTP3.

Así que, siguiendo uno de los tantos manuales para ello que hay en Internet, este por ejemplo, me dispuse a aplicar un “parche”. Después de identificar la parte correspondiente del código en el smali y modificarla (en varias ocasiones) al recompilar pues… no había forma de que funcionase.

Para qué engañarnos, hace cosa de 4 años que no he desarrollado nada de Android, y como he dicho antes cada desarrollador tiene sus mañas. Es probable que alguien con más experiencia no hubiese tenido problema en hacer esto.

La solución vino dada por Frida, recordé que meses atrás (año y pico) leí como en una con, habían empleado Burp y Frida para saltarse el SSLPinning. Me puse a leer y (EPIC WIN) encontré que había una forma de ver todo el tráfico de una aplicación haciendo uso de Frida y Burp. Aquí tenéis el link. El tuto está muy bien, pero me encontré con diversos “problemillas”, el principal debido a Android (la seguridad va mejorando). A causa de las nuevas versiones del sistema operativo, los certificados de usuario (en este caso) sirven para menos que un palo para hacer fotos. Así que tocaba poner el certificado propio (en este caso el generado por BURP) como CA, pero esto tiene truco, como leí a posteriori.

Llegados a este punto, nos ponemos manos a la obra:

Primer paso, generar el cert. En este caso con Burp por comodidad.

Una vez obtenido nuestro DER, será necesario “toquetearlo” un poco para que Android lo acepte. Por tanto habrá que hacer una conversión a PEM.

$ openssl x509 -inform DER -in cacert.der -out cacert.pem

Ahora, con el PEM ya generado (dada la amabilidad de Android) debemos darle un nombre concreto. Para ello, debemos obtener el hash del certificado, pero haciendo uso del algoritmo viejuno de openssl.

$ openssl x509 -inform PEM -subject_hash_old -in cacert.pem | head -1 9a5ba575

Ese hash que devuelve es el nombre que debemos darle al certificado (al PEM), pero acabado en 0.

9a5ba575.0

Y ahora es el momento de la “diversión”, o lo que es lo mismo, usar ADB root en una ROM de fabricante. En este caso todas las pruebas se han realizado haciendo uso de un BQ A4.5 con Android ONE en su versión 7.0 (la máxima disponible por parte del fabricante). Dado que es una ROM propia de BQ no es posible acceder desde ADB como root (adb root) pero sí que es posible elevar privilegios una vez hemos accedido a la shell del teléfono.

Pero antes hay que copiar el server de Frida que corresponda a nuestro terminal al dispositivo (realmente se puede copiar primero el cert creado, pero por mantener un orden y evitar reinicios tontos). Para identificar la versión adecuada hay que conocer el procesador empleado, para ello se ejecuta en la consola de Android:

getprop ro.product.cpu.abi

En el repositorio de Frida, se descarga la versión correspondiente del server, ARM en este caso y después de extraerlo:

./adb push ~/frida-server-android.arm /sdcard/Download/

Una vez copiado a la memoria del terminal, hay que copiar el servidor a una carpeta que permita ejecución,  /data/tmp/, cambiar el propietario (en mi caso) del usuario shell a root, y darle permisos de ejecución, como en cualquier máquina Linux.

Lo mismo con el cert que se ha creado:

 ./adb push ~/9a5ba575.0 /sdcard/Download/

Después de darle permisos (644), copiamos a la carpeta:

/system/etc/security/cacerts/

Ahora, viene el momento del reboot del móvil (o emulador). Se puede hacer con ADB, en el caso del emulador es mucho más cómodo a mi parecer.

Al iniciar el certificado que hemos metido, ya aparecerá dentro de las entidades certificadoras.

El siguiente paso, ejecutar el servidor de Frida. Entramos en la shell del terminal mediante ADB y elevamos privilegios. Vamos a /data/tmp y ejecutamos el servidor.

./frida-server-12.2.25-android-arm &

Si todo ha funcionado bien, al ejecutar en la terminal del equipo el siguiente comando, nos devolverá una lista con todos los servicios en ejecución en Android:

frida-ps -U

A continuación, viene la magia.

Java.perform(function() {                
 
    var array_list = Java.use("java.util.ArrayList");
    var ApiClient = Java.use('com.android.org.conscrypt.TrustManagerImpl');
 
    ApiClient.checkTrustedRecursive.implementation = function(a1,a2,a3,a4,a5,a6) {
            // console.log('Bypassing SSL Pinning');
            var k = array_list.$new(); 
            return k;
    }
 
},0);

Este fragmento de código, publicado por Mattia Vinci en techblog.mediaservice.net/ JS es el que permite hacer un bypass “fácilmente” del tan odiado SSL Pinning.

Pero primero habrá que arrancar BURP y “setear” la configuración de Android para que haga uso del proxy de éste.

Hecho esto, ya podemos ejecutar el JS indicando la aplicación que queremos auditar.

frida -U -l frida-ssl-pinning-bypass.js --no-paus -f org.s2grupo.valencia.APP

En el terminal se iniciará la aplicación en primer plano y las peticiones a servicios de esta aparecerán en BURP.

NOTA FINAL: Si la aplicación hace uso de servicios de Google (por ejemplo de la tienda de aplicaciones) o un WebView para autenticarse, será necesario deshabilitar el proxy de la configuración de Android. Aún investigo como poder pasarlo todo a BURP.

La entrada SSL pinning, I hate you! aparece primero en Security Art Work.