¿Qué era ese Wiper?

En abril de 2012, se se publicaron varias historias sobre un misterioso ataque malicioso que colapsaba los sistemas informáticos de varias empresas en Irán.

Algunos artículos mencionaban que el responsable era un virus llamado Wiper. Sin embargo, no se contaba con muestras de esos ataques, lo que generaba muchas dudas sobre la exactitud de esos informes.

A partir de estos incidentes, la Unión Internacional de Telecomunicaciones (ITU) solicitó a Kaspersky Lab que investigara los incidentes y determinara el potencial impacto destructivo de este nuevo programa malicioso.

Tras varias semanas de investigación, no logramos encontrar ningún programa malicioso que compartiera características con Wiper. Sin embargo, descubrimos la campaña de ciberespionaje con patrocinio estatal/nacional conocida como Flame y después como Gauss.

Estamos seguros de que Wiper era una cepa distinta a Flame. Aunque Flame era una plataforma de ataque de gran flexibilidad, no encontramos ninguna evidencia de comportamientos altamente destructivos. Dada la complejidad de Flame, uno esperaría que se usara en la vigilancia a largo plazo de blancos en lugar de ataques directos para sabotear sistemas informáticos. Por supuesto, es posible que una de las últimas etapas de la vigilancia fuese la distribución de una carga maliciosa vinculada con Wiper, pero hasta el momento no lo hemos constatado.

Entonces, meses después, seguimos preguntándonos ¿Qué era Wiper?

Penetrando en Wiper

Durante la investigación del misterioso ataque malicioso en abril, pudimos obtener y analizar varias imágenes de discos duros atacados por Wiper. Ahora podemos afirmar sin lugar a dudas que los incidentes ocurrieron y que el programa malicioso responsable de estos ataques existía en abril de 2012. Asimismo, sabemos ahora sobre otros incidentes muy similares que han estado ocurriendo desde diciembre de 2011.

La mayoría de los ataques sucedieron en los diez últimos días del mes (entre el 21 y el 30), aunque no podemos confirmar que se debiera a una función especial que se activara en determinadas fechas.

Los creadores de Wiper fueron muy cautelosos en destruir por completo cada dato que pudiera usarse como indicio para rastrear los incidentes. Entonces, en cada uno de los casos que hemos analizado, no quedó casi nada tras la activación de Wiper. Es importante remarcar lo de “casi nada” porque sí quedaron algunas huellas que nos permitieron entender mejor los ataques.

A partir de algunos de los sistemas destruidos tuvimos la suerte de recuperar una copia de la colmena de registro. Esta colmena de registro no contenía ningún controlador malicioso ni entradas de arranque. Sin embargo, se nos ocurrió buscar las entradas eliminadas en el espacio sobrante de la colmena. Esto es lo que encontramos:

Curiosamente, el 22 de abril, justo antes de que el sistema colapsara, se había creado una llave de registro específica, que después se borró. Esta llave era un servicio llamado “RAHDAUD64” y apuntaba a un archivo en el disco, llamado “~DF78.tmp”, en la carpeta “C:WINDOWSTEMP”.

En cuanto vimos esto, nos acordamos enseguida de Duqu que usaba nombres de archivos con este formato. En realidad, el nombre Duqu fue acuñado por el investigador húngaro Boldizsár Bencsáth del laboratorio CrySyS porque creaba archivos llamados “~dqXX.tmp”. (ver

Intentamos recuperar desde el disco el archivo “~DF78.tmp”, pero descubrimos que el espacio físico donde estaba alojado se había llenado con datos basura.

Detectamos el mismo patrón “borrador” en varios de los otros sistemas que analizamos: un servicio llamado “RAHDAUD64” que se eliminó justo antes de limpiarse, y su archivo lleno de datos basura. En estos otros sistemas, el servicio RAHDAUD64 apuntaba a diferentes nombres de archivos, como “~DF11.tmp” y “~DF3C.tmp”. Entonces, es posible que estos fueran nombres aleatorios.

Otra peculiaridad del proceso de limpieza fue un determinado patrón que se usaba como basurero para los archivos en el disco:

La mayoría de los archivos que se limpiaron contenían este determinado patrón que se repite una y otra vez. Curiosamente, no sobrescribía todo el archivo. En algunos casos, algunas porciones del archivo permanecieron intactas, pero en primer lugar se destruían todos los encabezados de los archivos. Quizás esto se debió al tamaño del archivo. El algoritmo de limpieza estaba diseñado para destruir rápidamente la mayor cantidad de archivos.

En base al patrón que sabemos que se usó para limpiar los archivos, recopilamos estadísticas de Kaspersky Security Network (KSN) sobre los archivos que se habían destruido.

En un intento por reconstruir el algoritmo Wiper, se nos ocurrió la siguiente secuencia:

1. Búsqueda y limpieza de archivos en base a sus extensiones.
   Lista de extensiones de archivos:

accdb	cdx	dmp	H	js	pnf	rom	tif	wmdb
acl	cfg	doc	hlp	json	png	rpt	tiff	wmv
acm	chk	docx	hpi	lnk	pps	rsp	tlb	xdr
amr	com	dot	htm	log	ppt	sam	tmp	xls
apln	cpl	drv	html	lst	pptx	scp	tsp	xlsx
asp	cpx	dwg	hxx	m4a	pro	scr	txt	xml
avi	dat	eml	ico	mid	psd	sdb	vbs	xsd
ax	db	exe	inc	nls	rar	sig	wab	zip
bak	dbf	ext	Ini	one	rar	sql	wab~	=
bin	dbx	fdb	jar	pdf	rdf	sqlite	wav	=
bmp	dll	gif	jpg	pip	resources	theme	wma	=

2. Búsqueda y limpieza de todos los archivos en determinadas carpetas (por ejemplo, Documents and Settings, Windows, Program Files) y en todos los dispositivos USB conectados al ordenador.
3. Limpieza de sectores de disco (posiblemente mediante un módulo bootkit).

La limpieza de un disco de varios cientos de gigabytes de capacidad puede tomar horas. Entonces los creadores del programa malicioso tuvieron el cuidado de seleccionar algoritmos de limpieza capaces de alcanzar un máximo de eficiencia. Por ejemplo, veamos el siguiente disco que limpió Wiper. Hemos recurrido a una representación estadística (entropía Shannon en bloques de 256K) para representar la entropía en el disco. Las áreas más livianas tienen mayor entropía, las áreas oscuras, menor. Las áreas en rojo tienen una entropía muy alta (datos altamente aleatorios).

Como podemos ver, Wiper hizo un trabajo muy bueno destruyendo la mayor parte del disco. Se puede observar una franja roja arriba que indica un área que ha sido bien limpiada. Aunque no se evidencia ningún patrón, una gran porción del disco está llena con datos basura. La operación de limpieza obviamente se concentró en el principio del disco y después afectó a la mitad del disco, antes de que el sistema colapsara.

Podemos obtener otra vista observando los sectores que se llenaron con el conocido patrón “%PNG / iHDR”. En rojo aparecen los bloques de sectores en los que se sobrescribió con este patrón:

Como puede verse, más de tres cuartos del disco se vieron afectados por la acción de Wiper, y una enorme porción de la información se perdió definitivamente.

En algunos casos, Wiper falló: observamos un sistema de 64-bit que Wiper no pudo activar. En este caso, descubrimos dos archivos en %TEMP% que se limpiaron con el conocido patrón PNG/iHDR, pero no ocurrió esto con todo el disco:

Suponemos que estos dos archivos, de los miles en %TEMP%, deben haberse destruido porque contenían datos relevantes para el ataque de Wiper. En otro de los sistemas que hemos analizado, además de estos archivos 20K-ish, encontramos dos archivos de 512 bytes llamados “~DF820A.tmp” y “~DF9FAF.tmp”, que también se limpiaron sin posibilidad alguna de recuperarlos.

Curiosamente, notamos que en algunos de los sistemas todos los archivos PNF en la carpeta INF Windows se limpiaron con prioridad preferente respecto al resto de los archivos. Una vez más, se trata de una conexión con Duqu y Stuxnet, que guardaban su cuerpo principal en archivos codificados “.PNF”.

Si el objetivo de los atacantes era asegurarse de que el programa malicioso Wiper nunca fuese descubierto, tiene sentido limpiar primero los componentes de este programa malicioso, y solo después limpiar los otros archivos capaces de colapsar el sistema.

Relación con Flame

Mientras buscábamos este escurridizo programa malicioso, nos encontramos con otra cosa. Sospechamos que Wiper usaba nombres de archivo como “~DF*.tmp” o “~DE*.tmp” en la carpeta TEMP, de manera que empezamos a buscarlos por medio de KSN. Durante este proceso, notamos que un inusual elevado número de ordenadores contenían el mismo nombre de archivo: ~DEB93D.tmp:

Este nombre parecía ser un buen indicador de que el archivo era parte de la plataforma Tilded, y de que estaba relacionado con Duqu y Stuxnet. El archivo parecía estar codificado, pero enseguida nos dimos cuenta de algo:

Duqu (Nov 3, 2010):
00: ED 6F C8 DA 30 EE D5 01

~DEB93D:
00: 6F C8 FA AA 40 C5 03 B8

En un golpe de suerte, nos dimos cuenta de que este archivo empezaba con los bytes “6F C8″ que también estaban presentes en el principio del cuerpo principal de Duqu PNF, en formato codificado, cargado por el controlador compilado el 3 de noviembre de 2010. Si no hubiese sido por esto, quizás nunca nos habríamos fijado en ~DEB93D.tmp, ya que su contenido parecía basura.

El algoritmo codificador era débil y un patrón parecía repetirse cada 4096 bytes. Ya que el algoritmo era débil, pudimos descifrarlo mediante el criptoanálisis estadístico, una conocida técnica usada para descifrar archivos en el análisis de programas maliciosos. Tras decodificar el archivo, vimos lo que parecían registros sniffer. Esto nos llevó a revisar más y encontramos otros archivos, modificados en la misma fecha, con nombres como “mssecmgr.ocx”, “EF_trace.log” o “to961.tmp”. El resto, como se dice, ya es historia. Es justo así como descubrimos Flame.

Entonces, ¿qué era Wiper?

No cabe duda sobre la existencia de un programa malicioso conocido como Wiper que atacó sistemas informáticos en Irán (y quizás en otras partes del mundo) hasta finales de abril de 2012.

Este programa malicioso estaba tan bien diseñado que cuando se activaba no quedaba ningún dato a salvo. Si bien hemos detectado huellas de la infección, este programa malicioso sigue siendo un misterio porque no hemos visto ningún otro incidente con el mismo patrón de Wiper, y no se han registrado detecciones de este programa malicioso en los componentes de detección proactiva incorporados en nuestras soluciones de seguridad.

Conclusiones

• Es posible que nunca lleguemos a saber qué era Wiper, pero en base a nuestra experiencia estamos razonablemente seguros de que si existió, y de que no tenía relación con Flame.
• Es posible que en alguna parte existan algunos ordenadores en los que este programa malicioso no se haya limpiado, pero aún no lo hemos constatado.
• Es posible que Wiper haya estado vinculado con Duqu y Stuxnet, por sus nombres de archivos en común, pero no podemos asegurarlo.
• Lo que sí es cierto, es que Wiper fue muy efectivo y ha dado lugar a imitadores potenciales, como Shamoon.
• El hecho de que el uso de Wiper llevara al descubrimiento de la campaña de ciberespionaje Flame, durante los últimos 4 a 5 años, plantea una gran interrogante: Si los mismos que crearon Duqu/Stuxnet/Flame también crearon Wiper, ¿valía la pena delatar la existencia de una compleja campaña de ciberespionaje como Flame sólo para destruir unos cuantos sistemas informáticos?