Hai varios grupos cibernéticos coñecidos que se especializan en roubar fondos de empresas rusas. Vimos ataques mediante lagoas de seguridade que permiten o acceso á rede do obxectivo. Unha vez que acceden, os atacantes estudan a estrutura da rede da organización e despregan as súas propias ferramentas para roubar fondos. Un exemplo clásico desta tendencia son os grupos de hackers Buhtrap, Cobalt e Corkow.
O grupo RTM no que se centra este informe forma parte desta tendencia. Usa malware especialmente deseñado escrito en Delphi, que veremos con máis detalle nas seguintes seccións. Os primeiros rastros destas ferramentas no sistema de telemetría ESET foron descubertos a finais de 2015. O equipo carga varios módulos novos nos sistemas infectados segundo sexa necesario. Os ataques están dirixidos a usuarios de sistemas bancarios remotos en Rusia e algúns países veciños.
1. Goles
A campaña RTM está dirixida a usuarios corporativos; isto é obvio polos procesos que os atacantes intentan detectar nun sistema comprometido. O foco está no software de contabilidade para traballar con sistemas bancarios remotos.
A lista de procesos de interese para RTM aseméllase á lista correspondente do grupo Buhtrap, pero os grupos teñen diferentes vectores de infección. Se Buhtrap utilizou páxinas falsas con máis frecuencia, entón RTM utilizou ataques de descarga drive-by (ataques ao navegador ou aos seus compoñentes) e spam por correo electrónico. Segundo os datos de telemetría, a ameaza está dirixida a Rusia e varios países próximos (Ucraína, Casaquistán, República Checa, Alemaña). Non obstante, debido ao uso de mecanismos de distribución masiva, a detección de malware fóra das rexións de destino non é sorprendente.
O número total de deteccións de malware é relativamente pequeno. Por outra banda, a campaña RTM utiliza programas complexos, o que indica que os ataques están moi dirixidos.
Descubrimos varios documentos de señuelo utilizados por RTM, incluídos contratos, facturas ou documentos de contabilidade fiscal inexistentes. A natureza dos señuelos, combinada co tipo de software obxecto do ataque, indica que os atacantes están "entrando" nas redes de empresas rusas a través do departamento de contabilidade. O grupo actuou seguindo o mesmo esquema en 2014-2015
Durante a investigación, puidemos interactuar con varios servidores C&C. Listaremos a lista completa de comandos nas seguintes seccións, pero polo de agora podemos dicir que o cliente transfire os datos do keylogger directamente ao servidor atacante, desde o que se reciben comandos adicionais.
Non obstante, desapareceron os días nos que simplemente podía conectarse a un servidor de comandos e control e recoller todos os datos que lle interesaban. Recreamos ficheiros de rexistro realistas para obter algúns comandos relevantes do servidor.
O primeiro deles é unha solicitude ao bot para que transfira o ficheiro 1c_to_kl.txt, un ficheiro de transporte do programa 1C: Enterprise 8, cuxa aparición é supervisada activamente por RTM. 1C interactúa cos sistemas bancarios remotos cargando datos sobre pagos saíntes nun ficheiro de texto. A continuación, o ficheiro envíase ao sistema bancario remoto para a automatización e a execución da orde de pagamento.
O ficheiro contén detalles de pago. Se os atacantes cambian a información sobre os pagos saíntes, a transferencia enviarase con detalles falsos ás contas dos atacantes.
Aproximadamente un mes despois de solicitar estes ficheiros ao servidor de comandos e control, observamos que se cargaba un novo complemento, 1c_2_kl.dll, no sistema comprometido. O módulo (DLL) está deseñado para analizar automaticamente o ficheiro de descarga penetrando nos procesos do software de contabilidade. Describirémolo en detalle nas seguintes seccións.
Curiosamente, FinCERT do Banco de Rusia emitiu a finais de 2016 un boletín de advertencia sobre os cibercriminais que usan ficheiros de carga 1c_to_kl.txt. Os desenvolvedores de 1C tamén coñecen este esquema; xa fixeron unha declaración oficial e enumeraron as precaucións.
Tamén se cargaron outros módulos desde o servidor de comandos, en particular VNC (as súas versións de 32 e 64 bits). Semella o módulo VNC que se usaba anteriormente nos ataques troianos de Dridex. Este módulo úsase supostamente para conectarse remotamente a un ordenador infectado e realizar un estudo detallado do sistema. A continuación, os atacantes tentan moverse pola rede, extraendo contrasinais dos usuarios, recollendo información e garantindo a presenza constante de malware.
2. Vectores de infección
Na seguinte figura móstranse os vectores de infección detectados durante o período de estudo da campaña. O grupo usa unha ampla gama de vectores, pero principalmente ataques de descarga e spam. Estas ferramentas son convenientes para ataques dirixidos, xa que no primeiro caso, os atacantes poden seleccionar sitios visitados polas posibles vítimas e, no segundo, poden enviar correo electrónico con anexos directamente aos empregados da empresa desexados.
O malware distribúese a través de múltiples canles, incluídos os kits de explotación RIG e Sundown ou os correos de spam, que indican conexións entre os atacantes e outros ciberatacantes que ofrecen estes servizos.
2.1. Como están relacionados RTM e Buhtrap?
A campaña RTM é moi semellante a Buhtrap. A pregunta natural é: como se relacionan entre si?
En setembro de 2016, observamos que se distribuía unha mostra RTM mediante o cargador de Buhtrap. Ademais, atopamos dous certificados dixitais usados tanto en Buhtrap como en RTM.
O primeiro, supostamente emitido para a empresa DNISTER-M, utilizouse para asinar dixitalmente o segundo formulario Delphi (SHA-1: 025C718BA31E43DB1B87DC13F94A61A9338C11CE) e o DLL Buhtrap (SHA-1: 1E2642B454B2D889B6D 41116).
O segundo, emitido a Bit-Tredj, utilizouse para asinar os cargadores Buhtrap (SHA-1: 7C1B6B1713BD923FC243DFEC80002FE9B93EB292 e B74F71560E48488D2153AE2FB51207A0B206), así como os compoñentes de descarga e instalación RTM2EXNUMX.
Os operadores de RTM usan certificados que son comúns a outras familias de malware, pero tamén teñen un certificado único. Segundo a telemetría de ESET, emitiuse a Kit-SD e só se utilizou para asinar algún malware RTM (SHA-1: 42A4B04446A20993DDAE98B2BE6D5A797376D4B6).
RTM usa o mesmo cargador que Buhtrap, os compoñentes RTM cárganse desde a infraestrutura de Buhtrap, polo que os grupos teñen indicadores de rede similares. Non obstante, segundo as nosas estimacións, RTM e Buhtrap son grupos diferentes, polo menos porque RTM distribúese de diferentes xeitos (non só usando un descargador "estranxeiro").
A pesar diso, os grupos de hackers usan principios operativos similares. Diríxense ás empresas que usan software de contabilidade, recollen información do sistema, buscan lectores de tarxetas intelixentes e implementan unha serie de ferramentas maliciosas para espiar ás vítimas.
3. Evolución
Nesta sección, analizaremos as diferentes versións de malware atopadas durante o estudo.
3.1. Versionado
RTM almacena os datos de configuración nunha sección de rexistro, sendo a parte máis interesante o prefixo de botnet. Na seguinte táboa preséntase unha lista de todos os valores que vimos nas mostras que estudamos.
É posible que os valores se poidan usar para gravar versións de malware. Non obstante, non notamos moita diferenza entre versións como bit2 e bit3, 0.1.6.4 e 0.1.6.6. Ademais, un dos prefixos existe desde o principio e pasou dun dominio C&C típico a un dominio .bit, como se mostrará a continuación.
3.2. Horario
Usando datos de telemetría, creamos un gráfico da aparición de mostras.
4. Análise técnica
Nesta sección, describiremos as principais funcións do troiano bancario RTM, incluídos os mecanismos de resistencia, a súa propia versión do algoritmo RC4, o protocolo de rede, a funcionalidade de espionaxe e algunhas outras características. En particular, centrarémonos nas mostras SHA-1 AA0FA4584768CE9E16D67D8C529233E99FF1BBF0 e 48BC113EC8BA20B8B80CD5D4DA92051A19D1032B.
4.1. Instalación e aforro
4.1.1. Implementación
O núcleo RTM é unha DLL, a biblioteca cárgase no disco usando .EXE. O ficheiro executable normalmente está empaquetado e contén código DLL. Unha vez iniciado, extrae a DLL e execútaa usando o seguinte comando:
rundll32.exe “%PROGRAMDATA%Winlogonwinlogon.lnk”,DllGetClassObject host4.1.2. DLL
A DLL principal sempre se carga no disco como winlogon.lnk no cartafol %PROGRAMDATA%Winlogon. Esta extensión de ficheiro adoita estar asociada a un atallo, pero o ficheiro é en realidade unha DLL escrita en Delphi, denominada core.dll polo programador, como se mostra na imaxe de abaixo.
Пример названия DLL F4C746696B0F5BB565D445EC49DD912993DE6361
Unha vez lanzado, o troiano activa o seu mecanismo de resistencia. Isto pódese facer de dúas formas diferentes, dependendo dos privilexios da vítima no sistema. Se tes dereitos de administrador, o troiano engade unha entrada de Windows Update ao rexistro HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun. Os comandos contidos en Windows Update executaranse ao inicio da sesión do usuario.
HKLMSOFTWAREMicrosoftWindowsCurrentVersionRunWindows Update [REG_SZ] = rundll32.exe “%PROGRAMDATA%winlogon.lnk”, host DllGetClassObject
O troiano tamén tenta engadir unha tarefa ao Programador de tarefas de Windows. A tarefa lanzará a DLL winlogon.lnk cos mesmos parámetros que o anterior. Os dereitos de usuario habituais permiten ao troiano engadir unha entrada de Windows Update cos mesmos datos ao rexistro HKCUSoftwareMicrosoftWindowsCurrentVersionRun:
rundll32.exe “%PROGRAMDATA%winlogon.lnk”,DllGetClassObject host4.2. Algoritmo RC4 modificado
A pesar das súas deficiencias coñecidas, o algoritmo RC4 é usado regularmente polos autores de malware. Non obstante, os creadores de RTM modificárona lixeiramente, probablemente para dificultar a tarefa dos analistas de virus. Unha versión modificada de RC4 úsase amplamente en ferramentas RTM maliciosas para cifrar cadeas, datos de rede, configuración e módulos.
4.2.1. Diferenzas
O algoritmo orixinal RC4 inclúe dúas etapas: inicialización do bloque s (tamén coñecido como KSA - Key-Scheduling Algorithm) e xeración de secuencias pseudoaleatorias (PRGA - Pseudo-Random Generation Algorithm). A primeira etapa consiste na inicialización da s-box mediante a clave, e na segunda etapa o texto fonte procédese mediante a s-box para o cifrado.
Os autores de RTM engadiron un paso intermedio entre a inicialización da s-box e o cifrado. A clave adicional é variable e establécese ao mesmo tempo que os datos que se van cifrar e descifrar. A función que realiza este paso adicional móstrase na seguinte figura.
4.2.2. Cifrado de cadeas
A primeira vista, hai varias liñas lexibles na DLL principal. O resto cífranse mediante o algoritmo descrito anteriormente, cuxa estrutura se mostra na seguinte figura. Atopamos máis de 25 claves RC4 diferentes para o cifrado de cadeas nas mostras analizadas. A clave XOR é diferente para cada fila. O valor do campo numérico que separa as liñas é sempre 0xFFFFFFFF.
Ao comezo da execución, RTM descifra as cadeas nunha variable global. Cando é necesario acceder a unha cadea, o troiano calcula dinámicamente o enderezo das cadeas descifradas en función do enderezo base e do desplazamento.
As cadeas conteñen información interesante sobre as funcións do malware. Algúns exemplos de cadeas ofrécense na Sección 6.8.
4.3. Rede
A forma en que o malware RTM contacta co servidor C&C varía dunha versión a outra. As primeiras modificacións (outubro de 2015 - abril de 2016) utilizaron os nomes de dominio tradicionais xunto cunha fonte RSS en livejournal.com para actualizar a lista de comandos.
Desde abril de 2016, vimos un cambio aos dominios .bit nos datos de telemetría. Isto está confirmado pola data de rexistro do dominio: o primeiro dominio RTM fde05d0573da.bit rexistrouse o 13 de marzo de 2016.
Todos os URL que vimos durante o seguimento da campaña tiñan un camiño común: /r/z.php. É bastante inusual e axudará a identificar as solicitudes RTM nos fluxos de rede.
4.3.1. Canle para comandos e control
Exemplos legados utilizaron esta canle para actualizar a súa lista de servidores de comando e control. O aloxamento está situado en livejournal.com, no momento de escribir o informe permaneceu no URL hxxp://f72bba81c921(.)livejournal(.)com/data/rss.
Livejournal é unha empresa ruso-estadounidense que ofrece unha plataforma de blogs. Os operadores de RTM crean un blog de LJ no que publican un artigo con comandos codificados; vexa a captura de pantalla.
As cadeas de comando e control codifican mediante un algoritmo RC4 modificado (sección 4.2). A versión actual (novembro de 2016) da canle contén os seguintes enderezos de servidor de comando e control:
- hxxp://cainmoon(.)net/r/z.php
- hxxp://rtm(.)dev/0-3/z.php
- hxxp://vpntap(.)top/r/z.php
4.3.2. dominios .bit
Nas mostras RTM máis recentes, os autores conéctanse a dominios C&C mediante o dominio de nivel superior .bit TLD. Non está na lista de dominios de primeiro nivel da ICANN (Domain Name and Internet Corporation). Pola contra, usa o sistema Namecoin, que está construído sobre a tecnoloxía Bitcoin. Os autores de malware non adoitan usar o TLD .bit para os seus dominios, aínda que un exemplo deste uso xa se observou anteriormente nunha versión da botnet Necurs.
A diferenza de Bitcoin, os usuarios da base de datos distribuída Namecoin teñen a capacidade de gardar datos. A principal aplicación desta función é o dominio de nivel superior .bit. Pode rexistrar dominios que se almacenarán nunha base de datos distribuída. As entradas correspondentes na base de datos conteñen enderezos IP resoltos polo dominio. Este TLD é "resistente á censura" porque só o rexistrado pode cambiar a resolución do dominio .bit. Isto significa que é moito máis difícil deter un dominio malicioso usando este tipo de TLD.
O troiano RTM non incorpora o software necesario para ler a base de datos distribuída de Namecoin. Usa servidores DNS centrais como dns.dot-bit.org ou servidores OpenNic para resolver dominios .bit. Polo tanto, ten a mesma durabilidade que os servidores DNS. Observamos que algúns dominios do equipo xa non se detectaban despois de ser mencionados nunha publicación do blog.
Outra vantaxe do TLD .bit para hackers é o custo. Para rexistrar un dominio, os operadores deben pagar só 0,01 NK, o que corresponde a 0,00185 USD (a partir do 5 de decembro de 2016). A modo de comparación, domain.com custa polo menos 10 dólares.
4.3.3. Protocolo
Para comunicarse co servidor de comandos e control, RTM utiliza solicitudes HTTP POST con datos formateados mediante un protocolo personalizado. O valor da ruta é sempre /r/z.php; Axente de usuario Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0). Nas solicitudes ao servidor, os datos están formatados do seguinte xeito, onde os valores de compensación exprésanse en bytes:
Os bytes 0 a 6 non están codificados; os bytes que comezan por 6 codifican mediante un algoritmo RC4 modificado. A estrutura do paquete de resposta C&C é máis sinxela. Os bytes codifican desde 4 ata o tamaño do paquete.
A lista de posibles valores de bytes de acción preséntase na seguinte táboa:
O malware sempre calcula o CRC32 dos datos descifrados e compárao co que está presente no paquete. Se son diferentes, o troiano deixa caer o paquete.
Os datos adicionais poden conter varios obxectos, incluíndo un ficheiro PE, un ficheiro para buscar no sistema de ficheiros ou novos URL de comandos.
4.3.4. Panel
Observamos que RTM usa un panel nos servidores C&C. Captura de pantalla a continuación:
4.4. Signo característico
RTM é un troiano bancario típico. Non é de estrañar que os operadores queiran información sobre o sistema da vítima. Por unha banda, o bot recolle información xeral sobre o sistema operativo. Por outra banda, descobre se o sistema comprometido contén atributos asociados aos sistemas bancarios remotos rusos.
4.4.1. Información xeral
Cando se instala ou se inicia malware despois dun reinicio, envíase un informe ao servidor de comandos e control que contén información xeral, incluíndo:
- Franxa horaria;
- idioma predeterminado do sistema;
- credenciais de usuario autorizado;
- nivel de integridade do proceso;
- Nome de usuario;
- nome do ordenador;
- versión do SO;
- módulos adicionais instalados;
- programa antivirus instalado;
- lista de lectores de tarxetas intelixentes.
4.4.2 Sistema de banca a distancia
Un obxectivo típico de troia é un sistema bancario remoto, e RTM non é unha excepción. Un dos módulos do programa chámase TBdo, que realiza varias tarefas, entre elas a dixitalización de discos e o historial de navegación.
Ao escanear o disco, o troiano comproba se o software bancario está instalado na máquina. A lista completa dos programas obxectivo atópase na seguinte táboa. Despois de detectar un ficheiro de interese, o programa envía información ao servidor de comandos. As seguintes accións dependen da lóxica especificada polos algoritmos do centro de comandos (C&C).
RTM tamén busca patróns de URL no historial do teu navegador e as pestanas abertas. Ademais, o programa examina o uso das funcións FindNextUrlCacheEntryA e FindFirstUrlCacheEntryA e tamén verifica que cada entrada coincida co URL cun dos seguintes patróns:
Despois de detectar as pestanas abertas, o troiano contacta con Internet Explorer ou Firefox a través do mecanismo de intercambio dinámico de datos (DDE) para comprobar se a pestana coincide co patrón.
A comprobación do teu historial de navegación e das pestanas abertas realízase nun bucle WHILE (un bucle cunha condición previa) cunha pausa de 1 segundo entre comprobacións. Outros datos que se supervisan en tempo real trataranse no apartado 4.5.
Se se atopa un patrón, o programa infórmao ao servidor de comandos mediante unha lista de cadeas da seguinte táboa:
4.5 Seguimento
Mentres se executa o troiano, a información sobre as características do sistema infectado (incluída información sobre a presenza de software bancario) envíase ao servidor de comando e control. A impresión dixital prodúcese cando RTM executa por primeira vez o sistema de monitorización inmediatamente despois da exploración inicial do SO.
4.5.1. Banca a distancia
O módulo TBdo tamén se encarga de supervisar os procesos relacionados coa banca. Usa o intercambio dinámico de datos para comprobar as pestanas en Firefox e Internet Explorer durante a exploración inicial. Outro módulo TShell úsase para supervisar as fiestras de comandos (Internet Explorer ou File Explorer).
O módulo usa as interfaces COM IShellWindows, iWebBrowser, DWebBrowserEvents2 e IConnectionPointContainer para supervisar as fiestras. Cando un usuario navega a unha nova páxina web, o malware observa isto. A continuación, compara o URL da páxina cos patróns anteriores. Despois de detectar unha coincidencia, o troiano toma seis capturas de pantalla consecutivas cun intervalo de 5 segundos e envíaas ao servidor de comandos de C&S. O programa tamén verifica algúns nomes de ventás relacionados co software bancario; a lista completa está a continuación:
4.5.2. Tarxeta intelixente
RTM permítelle supervisar os lectores de tarxetas intelixentes conectados a ordenadores infectados. Estes dispositivos utilízanse nalgúns países para conciliar ordes de pago. Se este tipo de dispositivo está conectado a un ordenador, podería indicarlle a un troiano que a máquina está a ser utilizada para transaccións bancarias.
A diferenza doutros troianos bancarios, RTM non pode interactuar con tales tarxetas intelixentes. Quizais esta funcionalidade estea incluída nun módulo adicional que aínda non vimos.
4.5.3. Keylogger
Unha parte importante do seguimento dun PC infectado é capturar as pulsacións de teclas. Parece que aos desenvolvedores de RTM non lles falta ningunha información, xa que supervisan non só as teclas habituais, senón tamén o teclado virtual e o portapapeis.
Para iso, use a función SetWindowsHookExA. Os atacantes rexistran as teclas presionadas ou as teclas correspondentes ao teclado virtual, xunto co nome e data do programa. O búfer envíase entón ao servidor de comandos C&C.
A función SetClipboardViewer úsase para interceptar o portapapeis. Os piratas informáticos rexistran o contido do portapapeis cando os datos son texto. O nome e a data tamén se rexistran antes de enviar o búfer ao servidor.
4.5.4. Capturas de pantalla
Outra función RTM é a interceptación de capturas de pantalla. A función aplícase cando o módulo de vixilancia da fiestra detecta un sitio ou un software bancario de interese. As capturas de pantalla tómanse usando unha biblioteca de imaxes gráficas e transfírense ao servidor de comandos.
4.6. Desinstalación
O servidor C&C pode evitar que se execute o malware e limpar o teu ordenador. O comando permítelle borrar os ficheiros e as entradas de rexistro creadas mentres se executa RTM. Despois, usando o DLL, elimínanse o malware e o ficheiro winlogon, despois de que o comando apaga o ordenador. Como se mostra na imaxe de abaixo, a DLL é eliminada polos desenvolvedores que usan erase.dll.
O servidor pode enviar ao troiano un comando destrutivo de desinstalación e bloqueo. Neste caso, se tes dereitos de administrador, RTM eliminará o sector de arranque MBR do disco duro. Se isto falla, o troiano tentará cambiar o sector de arranque MBR a un sector aleatorio; entón o ordenador non poderá iniciar o sistema operativo despois do apagado. Isto pode levar a unha reinstalación completa do SO, o que significa a destrución das probas.
Sen privilexios de administrador, o malware escribe un .EXE codificado na DLL RTM subxacente. O executable executa o código necesario para apagar o ordenador e rexistra o módulo na clave de rexistro HKCUCurrentVersionRun. Cada vez que o usuario inicia unha sesión, o ordenador apágase inmediatamente.
4.7. O ficheiro de configuración
Por defecto, RTM non ten case ningún ficheiro de configuración, pero o servidor de comandos e control pode enviar valores de configuración que serán almacenados no rexistro e utilizados polo programa. A lista de claves de configuración preséntase na seguinte táboa:
A configuración gárdase na clave de rexistro de Software[Cadea pseudoaleatoria]. Cada valor corresponde a unha das filas presentadas na táboa anterior. Os valores e os datos son codificados mediante o algoritmo RC4 en RTM.
Os datos teñen a mesma estrutura que unha rede ou cadeas. Engádese unha clave XOR de catro bytes ao comezo dos datos codificados. Para os valores de configuración, a clave XOR é diferente e depende do tamaño do valor. Pódese calcular do seguinte xeito:
xor_key = (len(config_value) << 24) | (len(config_value) << 16)
| len(valor_configuración)| (len(config_value) << 8)
4.8. Outras funcións
A continuación, vexamos outras funcións que admite RTM.
4.8.1. Módulos adicionais
O troiano inclúe módulos adicionais, que son ficheiros DLL. Os módulos enviados desde o servidor de comandos C&C pódense executar como programas externos, reflectirse na memoria RAM e lanzarse en novos fíos. Para o almacenamento, os módulos gárdanse en ficheiros .dtt e codifican mediante o algoritmo RC4 coa mesma clave utilizada para as comunicacións de rede.
Ata agora observamos a instalación do módulo VNC (8966319882494077C21F66A8354E2CBCA0370464), o módulo de extracción de datos do navegador (03DE8622BE6B2F75A364A275995C3411626C4D9E_1) e o módulo C2D1E_562_1 EFC69FBA6 B58BE88753D7B0E3CFAB).
Para cargar o módulo VNC, o servidor C&C emite un comando solicitando conexións co servidor VNC nun enderezo IP específico no porto 44443. O complemento de recuperación de datos do navegador executa TBrowserDataCollector, que pode ler o historial de navegación de IE. Despois envía a lista completa de URL visitados ao servidor de comandos C&C.
O último módulo descuberto chámase 1c_2_kl. Pode interactuar co paquete de software 1C Enterprise. O módulo inclúe dúas partes: a parte principal - DLL e dous axentes (32 e 64 bits), que se inxectarán en cada proceso, rexistrando unha vinculación a WH_CBT. Despois de ser introducido no proceso 1C, o módulo vincula as funcións CreateFile e WriteFile. Sempre que se chama á función de enlace CreateFile, o módulo almacena a ruta do ficheiro 1c_to_kl.txt na memoria. Despois de interceptar a chamada WriteFile, chama á función WriteFile e envía a ruta do ficheiro 1c_to_kl.txt ao módulo DLL principal, pasándolle a mensaxe WM_COPYDATA de Windows elaborada.
O módulo DLL principal abre e analiza o ficheiro para determinar as ordes de pago. Recoñece o importe e o número de transacción contidos no ficheiro. Esta información envíase ao servidor de comandos. Cremos que este módulo está actualmente en desenvolvemento porque contén unha mensaxe de depuración e non pode modificar automaticamente 1c_to_kl.txt.
4.8.2. Escalada de privilexios
RTM pode tentar aumentar os privilexios mostrando mensaxes de erro falsas. O malware simula unha comprobación do rexistro (ver imaxe a continuación) ou usa unha icona de editor de rexistro real. Teña en conta a falta de ortografía esperar - qué. Despois duns segundos de dixitalización, o programa mostra unha mensaxe de erro falsa.
Unha mensaxe falsa enganará facilmente ao usuario medio, a pesar dos erros gramaticais. Se o usuario fai clic nunha das dúas ligazóns, RTM tentará aumentar os seus privilexios no sistema.
Despois de seleccionar unha das dúas opcións de recuperación, o troiano inicia a DLL usando a opción runas na función ShellExecute con privilexios de administrador. O usuario verá un aviso real de Windows (ver imaxe a continuación) para a elevación. Se o usuario dá os permisos necesarios, o troiano executarase con privilexios de administrador.
Dependendo do idioma predeterminado instalado no sistema, o troiano mostra mensaxes de erro en ruso ou inglés.
4.8.3. Certificado
RTM pode engadir certificados á tenda de Windows e confirmar a fiabilidade da adición facendo clic automaticamente no botón "si" no cadro de diálogo csrss.exe. Este comportamento non é novo; por exemplo, o troiano bancario Retefe tamén confirma de forma independente a instalación dun novo certificado.
4.8.4. Conexión inversa
Os autores de RTM tamén crearon o túnel TCP de Backconnect. Aínda non vimos a función en uso, pero está deseñada para supervisar remotamente os ordenadores infectados.
4.8.5. Xestión de ficheiros de host
O servidor C&C pode enviar un comando ao troiano para modificar o ficheiro host de Windows. O ficheiro host úsase para crear resolucións DNS personalizadas.
4.8.6. Buscar e enviar un ficheiro
O servidor pode solicitar buscar e descargar un ficheiro no sistema infectado. Por exemplo, durante a investigación recibimos unha solicitude para o ficheiro 1c_to_kl.txt. Como se describiu anteriormente, este ficheiro é xerado polo sistema de contabilidade 1C: Enterprise 8.
4.8.7. Actualización
Finalmente, os autores de RTM poden actualizar o software enviando unha nova DLL para substituír a versión actual.
5. Conclusión
A investigación de RTM mostra que o sistema bancario ruso aínda atrae a atacantes cibernéticos. Grupos como Buhtrap, Corkow e Carbanak rouban con éxito diñeiro das entidades financeiras e dos seus clientes en Rusia. RTM é un novo xogador nesta industria.
Segundo a telemetría de ESET, as ferramentas RTM maliciosas están en uso polo menos desde finais de 2015. O programa ten unha gama completa de capacidades de espionaxe, incluíndo ler tarxetas intelixentes, interceptar as pulsacións de teclas e supervisar transaccións bancarias, así como buscar ficheiros de transporte 1C: Enterprise 8.
O uso dun dominio de nivel superior .bit descentralizado e sen censura garante unha infraestrutura altamente resistente.
Fonte: www.habr.com