Los actores de amenazas utilizaron una pieza de software de comunicación corporativa muy apreciada de 3CX, según los expertos en seguridad. En particular, los informes indican que se utilizó un cliente de escritorio para el servicio 3CX VoIP (Voz sobre Protocolo de Internet) para apuntar específicamente a los clientes de 3CX.
Se cree que el ataque es un proceso de varias partes, con la primera etapa utilizando una versión pirateada de la aplicación de escritorio 3CX. Aunque el archivo.exe y el paquete MSI tienen el mismo nombre, investigaciones preliminares indican que el paquete MSI es el que puede incluir DLL que se han modificado maliciosamente.
El comienzo del proceso de infección ocurre cuando 3CXDesktopApp.exe carga el archivo ffmpeg.dll. Después de eso, ffmpeg.dll leerá el código encriptado de d3dcompiler_47.dll y luego lo decodificará. Parece que el código descifrado es la carga útil de la puerta trasera que intenta visitar la página de IconStorage GiHub para acceder a un archivo ICO que contiene el servidor C&C cifrado al que se conecta la puerta trasera para adquirir la carga útil final probable.
No es una coincidencia que los actores de amenazas responsables de este ataque eligieran estas dos DLL (ffmpeg y d3dcompiler_47) como objetivos para su ataque. La aplicación en cuestión, conocida como 3CXDesktopApp, fue desarrollada usando el framework de código abierto Electron. Ambas bibliotecas en cuestión a menudo se distribuyen junto con el tiempo de ejecución de Electron. Como resultado, es muy poco probable que despierten sospechas en el entorno de los clientes individuales. Además, el archivo manipulado, d3dcompiler 47, está firmado con un certificado que se le otorgó a Microsoft Corporation, y los detalles de la firma digital para Windows reflejan que no hay problemas asociados a la firma.
En este caso, la “pistola humeante” fue una combinación de shellcode encriptado RC4 que se insertó en el apéndice de firma de d3dcompiler y una referencia a la biblioteca d3dcompiler que se introdujo en la biblioteca ffmpeg. Ambas cosas se agregaron a la biblioteca ffmpeg.
Windows mostrará una notificación que dice que “la firma digital del elemento no se validó” cada vez que se actualice un ejecutable firmado, pero a pesar de que somos conscientes de que se modificó la DLL d3dcompiler_47.dll, Windows continuó mostrándola como firmada. Esto es a pesar de que somos conscientes del hecho de que fue modificado.
Parece que la DLL está abusando de la falla CVE-2013-3900, que se conoce como “vulnerabilidad de validación de firma WinVerifyTrust”.
El 10 de diciembre de 2013, Microsoft fue la primera empresa en divulgar públicamente esta vulnerabilidad. En ese momento, la compañía explicó que es posible agregar contenido a la sección de firma del código de autenticación de un EXE (la estructura del CERTIFICADO WIN) en un ejecutable firmado sin invalidar la firma.
Microsoft tomó la decisión final de hacer que la corrección fuera opcional, muy probablemente porque invalidaría los ejecutables genuinos y firmados que contenían datos en el bloque de firma de un ejecutable. Como resultado, Microsoft tomó la decisión de hacer que la actualización fuera opcional.
De acuerdo con la divulgación hecha por Microsoft para el CVE-2013-3900, la compañía cambió la forma en que se verifican las firmas para los archivos binarios firmados con el formato de firma Windows Authenticode con el lanzamiento de una actualización el 10 de diciembre de 2013. Esta actualización estuvo disponible para todas las versiones compatibles de Microsoft Windows.
Esta modificación se puede activar de forma voluntaria si se desea. Cuando se habilita el nuevo comportamiento para la verificación de firma de Windows Authenticode, Windows ya no considerará los archivos binarios no compatibles como firmados y ya no permitirá que se almacene información innecesaria en WIN. Estructura del CERTIFICADO.
Aunque han pasado cerca de 10 años desde que se descubrió la vulnerabilidad, y aunque se sabe que varios actores de amenazas la están explotando, el remedio sigue siendo una función opcional que solo se puede activar modificando manualmente el Registro de Windows. Para empeorar las cosas, incluso si agrega las entradas del Registro para aplicar la actualización, se eliminarán después de actualizar a Windows 11, lo que hace que su dispositivo sea vulnerable una vez más.
Las empresas que posiblemente se vean afectadas deben dejar de usar de inmediato la versión vulnerable del software, dlls si es factible e implementar parches o medidas de mitigación, si están disponibles. El personal de TI y de seguridad también debe buscar compilaciones y binarios comprometidos probados y observar actividad anormal en los procesos de 3CX, con una atención particular en el tráfico de C&C.
Mientras tanto, la activación de la supervisión del comportamiento en las soluciones de seguridad puede ayudar a determinar si se está produciendo o no un ataque dentro del sistema.
Es un conocido experto en seguridad móvil y análisis de malware. Estudió Ciencias de la Computación en la NYU y comenzó a trabajar como analista de seguridad cibernética en 2003. Trabaja activamente como experto en antimalware. También trabajó para empresas de seguridad como Kaspersky Lab. Su trabajo diario incluye investigar sobre nuevos incidentes de malware y ciberseguridad. También tiene un profundo nivel de conocimiento en seguridad móvil y vulnerabilidades móviles.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad
