El ataque se inició con un archivo aparentemente habitual y terminó en la pérdida total de control.

Incluso una factura habitual puede desencadenar una compleja cadena de infección, y fue precisamente ese esquema el que el grupo SilverFox empleó contra una empresa industrial japonesa al intentar instalar el troyano de acceso remoto ValleyRAT.
Según Cato Networks, el ataque comenzó con un correo de phishing que contenía una factura falsa. A la víctima se le ofrecía descargar un archivo ZIP a través de la infraestructura legítima de QQ, tras lo cual el cargador obtenía archivos adicionales desde la nube de Tencent. Los delincuentes contaban con que los servicios de confianza harían que el tráfico malicioso pareciera actividad de red normal.
El archivo ZIP incluía la biblioteca maliciosa PDFCORE8.dll y uno de dos programas legítimos, ConvertToPDF.exe o PDFDirect.exe. Los atacantes colocaban los archivos en la misma carpeta, a veces renombrando la aplicación como MicrosoftEdgeUpdate.exe. Al iniciarse, el programa cargaba automáticamente la biblioteca maliciosa situada en la misma carpeta. Esta técnica se denomina carga lateral de DLL.
PDFCORE8.dll dirigía el resto del ataque. Dentro de la biblioteca había tres controladores vulnerables cifrados: BootRepair.sys, EnPortv.sys y wsftprm.sys. SilverFox instalaba uno de ellos como servicio del sistema y, mediante acceso al núcleo de Windows, terminaba procesos de antivirus y de monitorización. BootRepair.sys y EnPortv.sys no se habían vinculado anteriormente con operaciones del grupo.
Tras debilitar las defensas, el malware restauraba la biblioteca del sistema ntdll.dll desde una copia limpia para eliminar los interceptores de llamadas integrados por las herramientas de seguridad. Luego el cargador creaba un proceso svchost.exe en estado suspendido, escribía el código en su memoria y cambiaba el punto de reanudación del hilo. Como resultado, ValleyRAT se ejecutaba dentro de un proceso de sistema de confianza.
Para mantener el acceso, SilverFox creaba una tarea programada, almacenaba el código y la configuración en el registro de Windows y empleaba dos mecanismos de recuperación. El cargador reiniciaba el código inyectado tras una detención, y un script por separado comprobaba el cargador cada 30 segundos y lo restauraba si había terminado.
En el incidente investigado, la plataforma de protección Cato bloqueó PDFCORE8.dll antes de la instalación de ValleyRAT. Los expertos recomiendan monitorizar el lanzamiento de ConvertToPDF.exe y PDFDirect.exe desde carpetas temporales, la carga de PDFCORE8.dll, la instalación de controladores sospechosos, el cambio de contexto de un svchost.exe en estado suspendido y la escritura de datos binarios en las claves HKCU\Console\0 y HKLM\SOFTWARE\IpDates_sun.