RATKing: nova campaña con troianos de acceso remoto
A finais de maio, descubrimos unha campaña para distribuír malware de troia de acceso remoto (RAT), programas que permiten aos atacantes controlar de forma remota un sistema infectado.
O grupo que examinamos distinguiuse polo feito de que non seleccionou ningunha familia específica de RAT para a infección. Varios troianos notáronse nos ataques dentro da campaña (todos eles estaban amplamente dispoñibles). Con esta característica, o grupo lembrounos ao rei das ratas, un animal mítico que consiste en roedores coas colas entrelazadas.
O orixinal está tirado da monografía de K. N. Rossikov "Ratos e roedores parecidos ao rato, os máis importantes economicamente" (1908)
En homenaxe a esta criatura, chamamos RATKing ao grupo que estamos considerando. Nesta publicación, entraremos en detalles sobre como os atacantes levaron a cabo o ataque, que ferramentas utilizaron e tamén compartiremos as nosas opinións sobre a atribución desta campaña.
Progreso do ataque
Todos os ataques desta campaña tiveron lugar segundo o seguinte algoritmo:
O usuario recibiu un correo electrónico de phishing cunha ligazón a Google Drive.
Usando a ligazón, a vítima descargou un script VBS malicioso que especificaba unha biblioteca DLL para cargar a carga útil final no rexistro de Windows e lanzou PowerShell para executalo.
A biblioteca DLL inxectou a carga útil final -de feito, unha das RAT utilizadas polos atacantes- no proceso do sistema e rexistrou un script VBS en execución automática para facerse un punto na máquina infectada.
A carga útil final executouse nun proceso do sistema e deulle ao atacante a capacidade de controlar o ordenador infectado.
Esquemáticamente pódese representar así:
A continuación, centrarémonos nas tres primeiras etapas, xa que nos interesa o mecanismo de entrega de malware. Non describiremos en detalle o mecanismo de funcionamento do propio malware. Están dispoñibles amplamente -ben se venden en foros especializados, ou mesmo se distribúen como proxectos de código aberto- e, polo tanto, non son exclusivos do grupo RATKing.
Análise das fases de ataque
Fase 1. Correo electrónico de phishing
O ataque comezou coa vítima recibindo unha carta maliciosa (os atacantes utilizaron diferentes modelos con texto; a captura de pantalla a continuación mostra un exemplo). A mensaxe contiña unha ligazón a un repositorio lexítimo drive.google.com, o que supostamente levou a unha páxina de descarga de documentos PDF.
Exemplo de correo electrónico de phishing
Non obstante, de feito, non se cargaba un documento PDF, senón un script VBS.
Cando fixo clic na ligazón do correo electrónico na captura de pantalla anterior, un ficheiro nomeado Cargo Flight Details.vbs. Neste caso, os atacantes nin sequera intentaron disimular o arquivo como un documento lexítimo.
Ao mesmo tempo, como parte desta campaña, descubrimos un guión denominado Cargo Trip Detail.pdf.vbs. Xa podería pasar por un PDF lexítimo porque Windows oculta as extensións de ficheiros por defecto. É certo, neste caso, a sospeita aínda podería ser espertada pola súa icona, que correspondía ao script VBS.
Nesta fase, a vítima podería recoñecer o engano: basta con botar unha ollada máis atenta aos ficheiros descargados por un segundo. Non obstante, nestas campañas de phishing, os atacantes adoitan depender dun usuario desatento ou apresurado.
Etapa 2. Operación do script VBS
O script VBS, que o usuario podía abrir sen querer, rexistrou unha biblioteca DLL no rexistro de Windows. O script estaba ofuscado: as liñas nel estaban escritas como bytes separados por un carácter arbitrario.
Exemplo de guión ofuscado
O algoritmo de desofuscación é bastante sinxelo: cada terceiro carácter foi excluído da cadea ofuscada, despois de que o resultado foi decodificado de base16 na cadea orixinal. Por exemplo, a partir do valor 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (resaltado na captura de pantalla anterior) a liña resultante foi WScript.Shell.
Para desofuscar cadeas, usamos a función Python:
def decode_str(data_enc):
return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)]))
A continuación, nas liñas 9-10, destacamos o valor cuxa desofuscación resultou nun ficheiro DLL. Foi el quen se lanzou na seguinte fase usando PowerShell.
Cadea con DLL ofuscada
Cada función do script VBS executouse a medida que se desofuscaban as cadeas.
Despois de executar o script, chamouse a función wscript.sleep — utilizouse para realizar execución aprazada.
A continuación, o script funcionou co rexistro de Windows. Utilizou a tecnoloxía WMI para iso. Coa súa axuda, creouse unha clave única e escribiuse o corpo do ficheiro executable no seu parámetro. Accedeuse ao rexistro a través de WMI mediante o seguinte comando:
Na terceira etapa, a DLL maliciosa cargou a carga útil final, inxectouna no proceso do sistema e asegurou que o script VBS se iniciase automaticamente cando o usuario iniciase sesión.
Executar a través de PowerShell
A DLL executouse usando o seguinte comando en PowerShell:
recibiu os datos do valor do rexistro co nome rnd_value_name — estes datos eran un ficheiro DLL escrito na plataforma .Net;
cargou o módulo .Net resultante na memoria do proceso powershell.exe utilizando a función [System.Threading.Thread]::GetDomain().Load()(descrición detallada da función Load(). dispoñible no sitio web de Microsoft);
realizou a función GUyyvmzVhebFCw]::EhwwK() - a execución da biblioteca DLL comezou con ela - con parámetros vbsScriptPath, xorKey, vbsScriptName... Parámetro xorKey almacenou a clave para descifrar a carga útil final e os parámetros vbsScriptPath и vbsScriptName foron transferidos para rexistrar un script VBS en execución automática.
Descrición da biblioteca DLL
En forma descompilada, o cargador de arranque tiña este aspecto:
Cargador en forma descompilada (a función coa que comezou a execución da biblioteca DLL está subliñada en vermello)
O cargador de arranque está protexido polo protector .Net Reactor. A utilidade de4dot fai un excelente traballo para eliminar este protector.
Este cargador:
inxectou a carga útil no proceso do sistema (neste exemplo, el svchost.exe);
Engadín un script VBS ao autorun.
Inxección de carga útil
Vexamos a función que chamou o script de PowerShell.
Función chamada polo script de PowerShell
Esta función realizou as seguintes accións:
descifrado dous conxuntos de datos (array и array2 na captura de pantalla). Orixinalmente comprimironse mediante gzip e criptáronse co algoritmo XOR coa chave xorKey;
datos copiados nas áreas de memoria asignadas. Datos de array - á área de memoria apuntada intPtr (payload pointer na captura de pantalla); datos de array2 - á área de memoria apuntada intPtr2 (shellcode pointer na captura de pantalla);
chamada función CallWindowProcA(описание Esta función está dispoñible no sitio web de Microsoft) cos seguintes parámetros (os nomes dos parámetros están listados a continuación, na captura de pantalla están na mesma orde, pero con valores de traballo):
lpPrevWndFunc - punteiro a datos de array2;
hWnd — punteiro a unha cadea que contén o camiño ao ficheiro executable svchost.exe;
Msg - punteiro a datos de array;
wParam, lParam — parámetros da mensaxe (neste caso, estes parámetros non se utilizaron e tiñan valores de 0);
creou un ficheiro %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.urlonde <name> - estes son os 4 primeiros caracteres do parámetro vbsScriptName (na captura de pantalla, o fragmento de código con esta acción comeza co comando File.Copy). Deste xeito, o malware engadiu un ficheiro URL á lista de ficheiros de execución automática cando o usuario iniciaba sesión e, polo tanto, se unía ao ordenador infectado. O ficheiro URL contiña unha ligazón ao script:
Para entender como se levou a cabo a inxección, desciframos as matrices de datos array и array2. Para iso utilizamos a seguinte función de Python:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
Como resultado, descubrimos que:
array foi un ficheiro PE: esta é a carga útil final;
array2 era o shellcode necesario para realizar a inxección.
Shellcode desde unha matriz array2 pasou como valor de función lpPrevWndFunc nunha función CallWindowProcA. lpPrevWndFunc — función de devolución de chamada, o seu prototipo ten o seguinte aspecto:
Entón, cando executas a función CallWindowProcA con parámetros hWnd, Msg, wParam, lParam execútase o shellcode da matriz array2 con argumentos hWnd и Msg. hWnd é un punteiro a unha cadea que contén o camiño ao ficheiro executable svchost.exeE Msg — punteiro á carga útil final.
O shellcode recibiu enderezos de funcións de kernel32.dll и ntdll32.dll baseándose nos valores hash dos seus nomes e inxectou a carga útil final na memoria do proceso svchost.exeusando a técnica de oco de proceso (podes ler máis sobre iso neste Artigo). Ao inxectar o shellcode:
creou un proceso svchost.exe en estado suspendido usando a función CreateProcessW;
entón ocultou a visualización da sección no espazo de enderezos do proceso svchost.exe utilizando a función NtUnmapViewOfSection. Así, o programa liberou a memoria do proceso orixinal svchost.exepara despois asignar memoria para a carga útil neste enderezo;
memoria asignada para a carga útil no espazo de enderezos do proceso svchost.exe utilizando a función VirtualAllocEx;
Inicio do proceso de inxección
escribiu o contido da carga útil no espazo de enderezos do proceso svchost.exe utilizando a función WriteProcessMemory (como na captura de pantalla a continuación);
retomou o proceso svchost.exe utilizando a función ResumeThread.
Finalización do proceso de inxección
Malware descargable
Como resultado das accións descritas, instalouse un dos varios programas maliciosos de clase RAT no sistema infectado. A seguinte táboa enumera o malware utilizado no ataque, que podemos atribuír con confianza a un grupo de atacantes, xa que as mostras accederon ao mesmo servidor de comandos e control.
Exemplos de malware distribuído co mesmo servidor de control
Aquí destacan dúas cousas.
En primeiro lugar, o feito mesmo de que os atacantes utilizaron varias familias de RAT diferentes á vez. Este comportamento non é típico dos cibergrupos coñecidos, que adoitan empregar aproximadamente o mesmo conxunto de ferramentas que lles son familiares.
En segundo lugar, RATKing usou malware que se vende en foros especializados a un prezo baixo ou mesmo é un proxecto de código aberto.
Ao final do artigo ofrécese unha lista máis completa do malware utilizado na campaña, cunha advertencia importante.
Sobre o grupo
Non podemos atribuír a campaña maliciosa descrita a ningún atacante coñecido. Polo momento, cremos que estes ataques foron realizados por un grupo fundamentalmente novo. Como escribimos ao principio, chamámoslle RATKing.
Para crear o script VBS, o grupo probablemente utilizou unha ferramenta similar á utilidade VBS-Crypter do desenvolvedor NYAN-x-CAT. Isto indícase pola semellanza do script que este programa crea co script dos atacantes. En concreto, ambos:
realizar a execución retardada mediante a función Sleep;
usar WMI;
rexistrar o corpo do ficheiro executable como un parámetro de clave de rexistro;
executa este ficheiro usando PowerShell no seu propio espazo de enderezos.
Para máis claridade, compare o comando de PowerShell para executar un ficheiro desde o rexistro, que é usado por un script creado mediante VBS-Crypter:
Teña en conta que os atacantes usaron outra utilidade de NYAN-x-CAT como unha das cargas útiles: Cal RAT.
Os enderezos dos servidores C&C indican outra característica distintiva de RATKing: o grupo prefire servizos DNS dinámicos (consulta a lista de C&C na táboa IoC).
IoC
A seguinte táboa ofrece unha lista completa de scripts VBS que probablemente se poden atribuír á campaña descrita. Todos estes scripts son similares e realizan aproximadamente a mesma secuencia de accións. Todos eles inxectan malware da clase RAT nun proceso de Windows de confianza. Todos eles teñen enderezos C&C rexistrados mediante servizos de DNS dinámico.
Non obstante, non podemos afirmar que todos estes scripts foron distribuídos polos mesmos atacantes, a excepción das mostras cos mesmos enderezos C&C (por exemplo, kimjoy007.dyndns.org).