Attor Espionaje a traves de GSM descubierto y periciado por Eset ( Empresa antivirus)

Apple y sus KTRR (Homenaje a Guardia Civil por sus 125 años y Dificultades encontrados en el caso DianaQuer )

Homenaje a la Guardia Civil Y Caso Diana(Apple no eres Infalible)

El caso de Magecart (caso sobre robo de identidad de tarjetas de crédito a través de tiendas online)

HIDE'N'SEEK: una respuesta adaptativapeer-to-peer IOT BOTNET

Autores del articulo:Adrian Þ endroiu y Vladimir Diaconescu

Bitdefender, Rumania

Cabe reseña que casis todas las web infectadas han corregido este problema, que las Empresas importantes ya han reparado esto hace meses y tomado medidas. Pero no por ello nos dejan de sorprender acciones de los criminales y acciones de las autoridades y empresa en busca de soluciones adecuadas. 

Basado en sus lazos históricos con el espacio, y la entrada de grupos de actores sofisticados como FIN6 y otros, es lógico concluir que Cobalt Group también entraría en este campo y continuaría diversificando sus esfuerzos criminales contra las instituciones financieras globales

Esta publicación de blog es una colaboración entre los equipos Malwarebytes y HYAS Threat Intelligence.

Magecart es un término que se ha convertido en un nombre familiar, y se refiere al robo de datos de tarjetas de crédito a través de tiendas en línea. El escenario más común es que los delincuentes comprometan los sitios de comercio electrónico mediante la inyección de código JavaScript falso diseñado para robar cualquier información ingresada por las víctimas en la página de pago.

La clasificación de los actores de amenazas de Magecart no es una tarea fácil debido a la diversidad de skimmers y su reutilización. El esfuerzo de atribuir Magecart a "grupos" comenzó con RiskIQ y el completo informe de Flashpoint Inside Magecart publicado en otoño de 2018, seguido por Group-IB varios meses después.

Mucho más recientemente, se ha presentado información sobre los actores de amenazas reales detrás de los grupos. Por ejemplo, IBM identificó públicamente al Grupo 6 como FIN6. Esto es interesante en muchos niveles porque refuerza la idea de que los grupos de amenazas existentes han estado aprovechando sus experiencias pasadas para aplicarlas al robo en el campo del comercio electrónico.

Un grupo que captó nuestro interés es el Grupo 4, que es una de las organizaciones cibercriminales más avanzadas. Al trabajar conjuntamente con la empresa de seguridad HYAS, encontramos algunos patrones interesantes en las direcciones de correo electrónico utilizadas para registrar dominios que pertenecen a Magecart que coinciden con los de un grupo de amenazas sofisticado conocido como Cobalt Group, también conocido como Cobalt Gang o Cobalt Spider.

En este blog, detallaremos nuestros hallazgos y mostraremos que el Grupo 4 no solo estaba llevando a cabo el desnatado del lado del cliente a través de JavaScript, sino que estaba, y probablemente lo sigue haciendo, el mismo lado del servidor. Es importante tener en cuenta que la mayoría de los informes sobre Magecart solo cubren el primero, que es mucho más fácil de identificar 

Magecart Group 4

En el informe Inside Magecart, el Grupo 4 se describe como avanzado y utiliza técnicas para combinarse con el tráfico normal. Por ejemplo, Magecart registrará nombres de dominio que parecen estar vinculados a anunciantes o proveedores analíticos (consulte los COI para los dominios del Grupo Cobalt identificados utilizando este TTP y la convención de nomenclatura). Otro aspecto interesante del informe es que se sospecha que el Grupo 4 ha tenido un historial de malware bancario.

Skimmer del lado del cliente 

Uno de los skimmers originales del Grupo 4 se ocultó como el complemento jquery.mask.js (consulte los IOC para obtener una copia del script). El código malicioso se agrega al final del script y utiliza algunas capas de ofuscación. Los datos codificados en hexadecimal se convierten en Base64, que se puede traducir a texto estándar para revelar la actividad del skimmer y una puerta de exfiltración.

Skimmer del lado del servidor

Al verificar la infraestructura relacionada con Magecart Group 4, identificamos un script PHP (ver IOC para la plantilla completa) que quizás se sirvió erróneamente como JavaScript en su lugar. De hecho, normalmente se necesitaría acceso al servidor de fondo para ver este tipo de archivo

Este describió una copia casi exacta de este guion en su publicación Swiper del lado del servidor con carga automática, el pequeño fragmento de código busca ciertas palabras clave asociadas con una transacción financiera y luego envía la solicitud y los datos de la cookie al servidor de exfiltración en secureqbrowser [.] Com. Denis Sinegubko de Sucuri

Conexiones entre registrantes de correo electrónico y puertas de exfiltración

Los dominios de skimmer del lado del cliente y del lado del servidor ilustrados anteriormente (bootstraproxy [.] Com y s3-us-west [.] Com) están registrados en robertbalbarran@protonmail.com. Están enumerados por RiskIQ en el Grupo 4 de Magecart: Nunca desapareció, simplemente avanzando IOCS .

Al verificar sus compuertas de exfiltración (secure.upgradenstore [.] Com y secureqbrowser [.] Com), los conectamos a otros correos electrónicos de registrantes y vimos surgir un patrón.

Las direcciones de correo electrónico utilizadas para registrar dominios de Magecart que pertenecen al Grupo 4 de Magecart contienen un [nombre], [inicial] y [apellido]. Ampliando nuestra búsqueda a otros dominios utilizados por el Grupo 4 y buscando a través del conjunto de datos Comox de HYAS, vemos que esta tendencia continúa

Sobre el grupo de Cobalt

Cobalt Group llegó a la vanguardia de la atención pública en el verano de 2016 con sus ataques de "premios gordos" contra las instituciones financieras en Europa, que supuestamente le dieron al grupo más de $ 3 millones. Desde entonces, supuestamente han acumulado más de mil millones de dólares de instituciones globales, evolucionando sus tácticas, técnicas y procedimientos a medida que avanzan.

Registro de dominio de Cobalt y otros TTP

Mientras cambiaban las tácticas a medida que evolucionaban, un patrón identificable en las convenciones de nombres de correo electrónico utilizadas históricamente por Cobalt permitió a HYAS no solo identificar dominios de campaña anteriores, sino que ayudó a vincular las campañas del Grupo Cobalt con los dominios de Magecart identificados anteriormente.

Un pequeño cambio de una de sus convenciones anteriores de [nombre], [apellido], [cuatro números] (utilizando abrumadoramente cuentas de protonmail, con un puñado de cuentas de correo electrónico tutanota / keemail.me) cambió a la convención de [nombre] mencionada anteriormente , [inicial], [apellido] nuevamente utilizando los mismos servicios de correo electrónico y registradores, y notablemente el mismo uso de los servicios de protección de la privacidad.

Dado el uso de servicios de privacidad para todos los dominios en cuestión, es altamente improbable que esta convención de nomenclatura sea conocida por cualquier otro actor además de aquellos que registraron la infraestructura de Cobalt Group y Magecart. Además, una investigación adicional reveló que, independientemente del proveedor de correo electrónico utilizado, 10 de las cuentas aparentemente separadas reutilizaron solo dos direcciones IP diferentes, incluso durante semanas y meses entre los registros.

Uno de esos correos electrónicos es petersmelanie@protonmail.com, que se utilizó para registrar 23 dominios, incluido my1xbet [.] Top. Este dominio se usó en una campaña de phishing que aprovecha CVE-2017-0199 con un documento señuelo llamado Fraud Transaction.doc

El mismo petersmelanie@protonmail.com también registró oracle-business [.] Com. Campañas similares contra Oracle y varios bancos se han atribuido a Cobalt Group , con, por ejemplo, el dominio oracle-system [.] Com.

Una amenaza creciente requiere trabajo continuo.

El uso de skimmers tanto del lado del cliente como del lado del servidor y los desafíos que esto plantea para identificar los compromisos de Magecart por parte de grupos de amenazas avanzados requiere el trabajo continuo de los socios de la industria para ayudar a defenderse de esta amenaza significativa y creciente. En ese sentido, los autores de esta publicación quisieran reconocer la contribución sustancial que los investigadores de la industria y los funcionarios encargados de hacer cumplir la ley están haciendo para combatir a grupos como el Cobalt, y esperan que la información contenida en este cuerpo de conocimiento se agregue a este corpus de conocimiento y fortalezca aún más estos esfuerzos.

El caso Asha y su campaña de casi un año (cuando la codicia puede con la honestidad)

Vamos a explicar un caso que afecto a casi 8 millones de usuarios en todo el mundo, ver como es de peligroso descargarse aplicaciones sin ton ni son, cuando habitualmente en un móvil están las aplicaciones que en un 90% de las veces cubren las necesidades de un usuario normal incluidos quienes usan para su trabajo diario.

En este caso se juntaron la colaboración de ESET (empresa de antivirus como principal investigadora y Google Play que puso los medios para evitar que desde su plataformas y Android siguieran distribuyendo este adware, y además acabaremos “cazando” al creador de dicho malware. Además de otras autoridades y autoridades académicas.

Se detecta una gran campaña de adware que se ejecutó durante casi un año y que afecto a cerca de 10 millones de teléfonos, de forma distribuida directa y posiblemente otros dos millones de distribución indirecta. Desde Google Play se informó sobre 8 millones de descargas. (sitio oficial).

Se identificaron 42 aplicaciones con el mismo adware en Google Play y pertenecientes uña campaña que se ejecutó desde julio 2018 y en el momento del descubrimiento del adware 21 aplicaciones todavía estaban activas y en descargas. 

Se reportó esto a Google e inmediatamente el equipo de seguridad de Google tomo cartas en el asunto eliminando dichas aplicaciones de su repositorio, pero sin poder controlar los repositorios de terceros y copias entre particulares.

ESET empresa de antivirus, detecta este adware como Android/AdDisplay/Ashas.

De todas ellas la más descargada y distribuida es Video downloadr master

Así era la manera en que Ashas realizaba su función de adware:

Aclarar primero que todas estas aplicaciones funcionaban de forma correcta a lo que indicaban en los móviles y tables Android, y de forma secundaria y escondida realizaban el adware que explicaremos a continuación.

Ashas y su adware interno

1.     Una vez iniciada la aplicación comenzaba a intentar comunicarse con su servidor C&C (cuya dirección IP estaba codificada en base64 dentro de la aplicación, no legible para ojos profanos).

2.    Una vez establecida la comunicación enviaba los datos al servidor del creador de este adware con los datos siguientes:         

a.        Tipo dispositivo

b.       Versión del sistema operativo

c.        Numero aplicaciones instaladas espacio de almacenamiento y espacio libre

d.       Si el dispositivo estaba rooteado.

e.        Verifica si el modo desarrollador está habilitado

f.        Si Facebook y FB Mesenger están instalados.

3 Envió de  información sobre dispositivo afectado

1. La aplicación recibe del servidor de C&C los datos necesarios para:
2.   Mostrar anuncio interesados por el atacante
3.  Sigilo no ser detectado
4. Resistencia a la desinstalación del programa una vez instalado, llegando a desinstalar solo parte gráfica i enlace link uso, pero no su parte interna que seguía en estado activo.

En cuanto a sigilo y a la resistencia el atacante usa varios trucos y estrategias

Estrategias de sigilo y ocultación:

1. La aplicación maliciosa intenta determinar si está siendo examinada por la seguridad de Google Play, Para este fin recibe del servidor C&C, recordar que es un servidor malicioso) un certificado IsGooglep, que indica si la dirección IP del dispositivo afectado se encuentra en un rango de direcciones IP conocida por los proveedores de Google y devuelve este indicativo como positivo; si el servidor devuelve este indicativo como positivo, la aplicación no activara la carga del adware. Para aclarar si dice SI no activo el adware.
2. La aplicación puede establecer un retraso personalizado entre anuncios, lo detectado es un retraso de 24 minutos desde que el teléfono se enciende y desbloquea para el primer anuncio, esto es para un proceso de prueba típico que lleva menos de 10 minutos, no detectara un comportamiento no deseado. Ademascuanto mas retraso y variado el usuario no detectara anuncios no deseados con aplicación particular.
3. Según respuesta del servidor, la aplicación también puede ocultar su icono y crear un acceso directo. Si un usuario típico intenta deshacer sede la aplicación maliciosa, es probable que solo elimina el acceso directo. La aplicación se ejecuta en plano oculto sin conocimiento del usuario ya que no hay indicativo en el sistema de información de Android. “Esta técnica de ocultación es muy popular entre aplicaciones relacionada con adware distribuida para Android desde distintas plataformas, incluida GooglePlay.
4. Una vez la aplicación maliciosa recibe sus datos de configuración (datos del usuario atacado), está lista para mostrar anuncios según elección del atacante, cada anuncio se muestra como una actividad de pantalla completa. Si un usuario desea verificar que aplicación es responsable del anuncio que se muestra, al presionar el botón “Aplicaciones recientes”, se utiliza otro “truco”, la aplicación muestra un icono de Facebook o Google, como se ve en la imagen siguiente, la aplicación imita estos dos iconos para parecer legítimo y evitar sospechas, y así permanecer en el anonimato y dispositivo del usuario el mayor tiempo posible.

Finalmente, la aplicación de la familia Ashass tenía un código oculto bajo el epígrafe de paquete com.google.xxx, este truco es para hacerse pasar por un servicio legítimo de Google, puede ayudar a evitar escrutinio. Algunos mecanismos de detección y entornos limitados pueden incluir en esta lista blanca dichos nombres de paquetes en un esfuerzo de evitar recursos imagen página siguiente.

A la caza del creador de este adware

Usando información de código abierto, rastreamos al desarrollador del adware e identificamos como operador de la campaña y propietario de C&C. En los siguientes párrafos describiremos como los esfuerzos de expertos en seguridad como ESET y proteger a los usuarios de este creador de adware.

La base de información del dominio de C6C registrado, identificamos el nombre del registrante, junto con otros datos como país de origen y dirección de correo electrónico como se ve en la siguiente figura

1.  Sabiendo que la información proporcionada del registrado en el dominio puede ser falsa, continuaremos con nuestra búsqueda. La dirección de correo electrónico y del país nos lleva a una lista de estudiantes de vietnamitas de una clase universitaria, lo que lo corrobora la existencia de la persona bajo cuyo nombre se registró el dominio.
2. Nombre del estudiante a que Universidad existe, su número de teléfono y otros datos que están fuera de esta investigación y no dependían de nosotros sino de la policía o autoridades competentes.
3. Según la dirección proporcionada por el creador del adware, (aun asumiendo es nombre falso) se encontró un repositorio en GitHub, su repositorio demuestra que es desarrollador de Android, pero no contenía ningún adware Asha al escribir el blog. Pero bajo una búsqueda en Google del nombre del paquete eliminados de adware, se encontró un proyecto “TestDelete” que había estado disponible en su repositorio borrado. Esto demuestra el intento de borrar huellas informáticas.
4. El desarrollador malicioso también se detecta en esta investigación de sus hazañas que coloco otras aplicaciones en App Store de Apple algunas con varias versiones de iOS algunas eliminadas de Google Play pero sin adwareAShas.
5. Siguiendo las actividades del desarrollador malicioso se encuentra un canal en YouTube propagando el adware Ashas y “sus otros proyectos”. En cuanto a la familia Ashas uno de sus videos promocionales Android e IOS fue visto casi 3 millones de veces.
6. Su canal de YouTube fue proporcionando ya una gran información de la persona real detrás de todo este adware incluso aparece su imagen en uno de sus videos promocionales y su perfil oficial de Facebook.
7. Vinculados a su perfil de Facebook del desarrollador malicioso descubren una página de Facebook, MinigamesHouse, y un dominio asociado.Net Este dominio asociado es similar al que uso el autor del malware para su comunicación de adwareC&C, Minigameshouse[.]us
8.  La comprobación de la página MinigamesHouse indica además que esta persona es realmente propietaria del dominio minigameshouse[].Us el número de teléfono registrado en el domino es el mismo de su página de Facebook.
9. Es interesante que en la página de Facebook de MinigameHouse, el desarrollador publicita muchos juegos más allá de la familia AShas para descargar a pesar de haber sido eliminados del repositorio oficial de Google Play y aun sabiendo que muchos de ellos no tienen adware.
10. Además, uno de sus videos de YouTube el desarrollador malicioso realiza un tutorial sobre desarrollo de un “juego instantáneo” para Facebook, sirve como ejemplo de seguridad operativa completamente ignorada. Pudimos ver que sus sitios visitados recientemente eran páginas de Google Play que pertenecen a aplicaciones con Ashas. También uso su cuenta de correo electrónico para iniciar sesión en servicios de video que los identifica como creador del adware sin duda alguna, y gracias al video se pudo identificar otras tres aplicaciones con Ashas incluido que estaban disponibles en GooglePlay

Conclusiones

Debido a la naturaleza del adware, este podía generar las siguientes acciones:

1.       Molestar al usuario con anuncios intrusivos, que no le interesan al usuario

2.       Gasto innecesario de recursos y batería

3.       Generar ganancias a creador a través de anuncios tele-dirigidos

4.       Recopilar datos del usuario, como datos filiales bancarios y otros.

5.     Ocultar su presencia en el dispositivo aun desinstalando la aplicación.

Usando solo código abierto y técnicas de investigación aquí descritas (otras evidentemente no públicas) se ha podido identificar de forma fehaciente al creador malicioso de adware y además poner cota a sus actos y tomar medidas por parte de las distribuidoras de software e aplicaciones

Debemos afrontar que el creador al no tomar precauciones debidas a su identidad, creemos que al principio fue honesto al intentar ganar dinero en Google Play con aplicaciones honesta, esto se demuestra que no todas sus aplicaciones tenían Adware, pero la codicia de querer ganar más le llevo por camino inadecuado.

Es de agradecer al equipo de ESET y especialmente a Lucas Stefankos, además del equipo de seguridad de Google Play en tomar las oportunas medidas

EL Caso de Amazon Alexa y Kindle

En los últimos años, cientos de millones de hogares se han vuelto "más inteligentes" y habilitados para Internet utilizando uno de los populares dispositivos de asistencia para el hogar. A pesar de los esfuerzos de algunos proveedores para desarrollar estos dispositivos teniendo en cuenta la seguridad.

El equipo de investigación de ESET Smart Home descubrió que incluso el popular Amazon Echo, el hardware original de Amazon Alexa, estaba abierto a vulnerabilidades de ataque de reinstalación de claves (KRACK). Este fue también el caso de al menos una generación de los lectores electrónicos Amazon Kindle ampliamente utilizados.

Todos los defectos identificados fueron reportados al equipo de seguridad de Amazon y posteriormente corregidos.

Ataques de KRACK

En 2017, dos investigadores belgas, Mathy Vanhoef y Frank Piessens, hicieron un anuncio sorprendente . Habían encontrado serias debilidades en el estándar WPA2, un protocolo que en ese momento aseguraba prácticamente todas las redes Wi-Fi modernas. Como se describe en su documento , los ataques KRACK estaban dirigidos principalmente contra el apretón de manos de cuatro vías, un mecanismo utilizado para dos propósitos: confirmar que tanto el cliente como el punto de acceso poseen las credenciales correctas, y negociar la clave utilizada para el cifrado del tráfico.

El equipo de Vanhoef descubrió que un adversario podría engañar a un dispositivo de la víctima para que reinicialice la clave por pares utilizada en la sesión actual (esta no es la contraseña de Wi-Fi) al elaborar y reproducir mensajes de apretón de manos criptográficos. Al explotar esta falla, un atacante puede reconstruir gradualmente la secuencia XOR de cifrado y luego detectar el tráfico de red de la víctima.

¿Qué estaba mal con Alexa?

Incluso dos años después, muchos dispositivos habilitados para Wi-Fi siguen siendo vulnerables a los ataques de KRACK. Como lo demostró el equipo de investigación de ESET Smart Home, esto incluía múltiples dispositivos de Amazon. Dado que Amazon vendió decenas de millones de Amazon Echos solo en los EE. UU. Y decenas de millones de Amazon Kindles , esto planteó un riesgo de seguridad de gran alcance.

Como parte de la investigación, probamos la primera generación de Amazon Echo (hardware original de Amazon Alexa) y la octava generación de Amazon Kindle. Nuestros experimentos se centraron principalmente en la resistencia de los dispositivos contra los diversos ataques de KRACK, utilizando los scripts disponibles por el equipo de Vanhoef .

Se descubrió que los dispositivos Echo de 1.a generación y Amazon Kindle de 8.a generación eran vulnerables a dos vulnerabilidades de KRACK. Utilizando los scripts de Vanhoef, pudimos

replicar la reinstalación de la clave de cifrado por pares (PTK-TK) en el protocolo de enlace de cuatro vías ( CVE-2017-13077 ) y la reinstalación de la clave de grupo (GTK) en el protocolo de enlace de cuatro vías ( CVE-2017-13078 ).

Figura 1

Amazon Echo 1ª generation reinstala las claves de cifrado (CVE-2017-13077)

Estas vulnerabilidades son bastante graves, ya que permiten que un atacante: reproducir paquetes antiguos para ejecutar un ataque DoS, interrumpir la comunicación de red o volver a atacar descifrar cualquier dato o información transmitida por la víctima dependiendo de la configuración de la red: falsificar paquetes de datos, hacer que el dispositivo descarte paquetes o incluso inyecte paquetes nuevos, interceptar información confidencial como contraseñas o cookies de sesión.

El asistente de inicio de Amazon también era susceptible a otra vulnerabilidad de red, no relacionada con KRACK: un ataque de repetición de transmisión: un ataque de red en el que una transmisión de transmisión válida se repite de manera fraudulenta y luego es aceptada por el dispositivo objetivo. Es un ataque de bajo nivel que un adversario puede abusar para lanzar un ataque de denegación de servicio (DoS) o recolectar paquetes para futuros criptoanálisis o ataques de fuerza bruta.

Figura 2

En la figura 2. Amazon Echo 1.a generación que acepta un mensaje de difusión reproducido.

Informes y parches

La investigación de ESET informó todas las vulnerabilidades identificadas en Echo y el Kindle de Amazon de octubre 23 de rd , 2018 y recibió el reconocimiento de la cuestión en la misma fecha. El January 8 º , 2019 ESET recibido la confirmación de que el equipo de seguridad de Amazon había replicado los problemas reportados, parches preparados y se distribuirlos a los usuarios en las próximas semanas.

Para parchear las vulnerabilidades CVE-2017-13077 y CVE-2017-13078 en varios millones de dispositivos Echo de 1.a generación y Amazon Kindle de 8.a generación, Amazon emitió y distribuyó una nueva versión del wpa_supplicant, una aplicación de software en el dispositivo cliente responsable de corregir autenticación a la red wifi.

Conclusión

El equipo de investigación de ESET Smart Home descubrió que los dispositivos Amazon Echo 1 st y Amazon Kindle 8 th generation eran susceptibles a varios ataques KRACK. Hemos informado todos los problemas identificados al fabricante para la revisión.

Cabe señalar que los ataques KRACK, similares a cualquier otro ataque contra redes Wi-Fi, requieren una proximidad cercana para ser efectivos. Esto significa que el atacante y los dispositivos de la víctima deben estar dentro del alcance de la misma red de radio Wi-Fi para que el compromiso tenga lugar.

Es poco probable que los ataques contra Amazon, y presumiblemente otros dispositivos, afecten significativamente la seguridad de la información enviada a través de la red. Esto se debe a que la mayor parte de los datos confidenciales están protegidos por medidas de seguridad adicionales por encima del cifrado estándar WPA / WPA2, es decir, HTTPS que utiliza el cifrado TLS.

Los exploits descritos anteriormente afectan únicamente la seguridad de WPA / WPA2. Si tiene éxito, el efecto sería similar a que la víctima use una red Wi-Fi desprotegida. Por lo tanto, el impacto práctico pertenecería principalmente a datos no protegidos adecuadamente por otras capas de red como TLS, o cuando se combinan con otras vulnerabilidades, y están más allá del alcance de este artículo.

En cualquier caso, recomendamos a todos los usuarios de Amazon que verifiquen, a través de su aplicación Echo y de la configuración de Kindle, que están utilizando el último firmware de Echo y Kindle .

Agradecimientos al Especialista de Conciencia de Seguridad de ESET, Ondrej Kubovič, por su ayuda con este artículo.