Ás veces realmente queres mirar aos ollos dalgún escritor de virus e preguntar: por que e por que? Podemos responder a pregunta "como" nós mesmos, pero sería moi interesante descubrir en que estaba pensando este ou aquel creador de malware. Sobre todo cando nos atopamos con tales "perlas".
O heroe do artigo de hoxe é un exemplo interesante de criptógrafo. Ao parecer, foi concibido como outro "ransomware", pero a súa implementación técnica semella máis a broma cruel de alguén. Hoxe falaremos desta implementación.
Desafortunadamente, é case imposible rastrexar o ciclo de vida deste codificador; hai moi poucas estatísticas sobre el, xa que, afortunadamente, non se estendeu. Polo tanto, deixaremos fóra a orixe, os métodos de infección e outras referencias. Falemos só do noso caso de reunión con Wulfric Ransomware e como axudamos ao usuario a gardar os seus ficheiros.
I. Como comezou todo
As persoas que foron vítimas de ransomware adoitan contactar co noso laboratorio antivirus. Ofrecemos asistencia independentemente dos produtos antivirus que teñan instalados. Esta vez contactouse con nós unha persoa cuxos ficheiros estaban afectados por un codificador descoñecido.
Boas tardes Os ficheiros foron cifrados nun almacenamento de ficheiros (samba4) cun inicio de sesión sen contrasinal. Sospeito que a infección veu do ordenador da miña filla (Windows 10 con protección estándar de Windows Defender). O ordenador da filla non se acendeu despois diso. Os ficheiros están cifrados principalmente .jpg e .cr2. Extensión do ficheiro despois do cifrado: .aef.
Recibimos do usuario mostras de ficheiros cifrados, unha nota de rescate e un ficheiro que probablemente sexa a clave que o autor do ransomware necesitaba para descifrar os ficheiros.
Aquí están todas as nosas pistas:
01c.aef (4481K)
hackeado.jpg (254K)
pirateado.txt (0K)
04c.aef (6540K)
clave de paso (0K)
Botámoslle un ollo á nota. Cantos bitcoins esta vez?
Tradución:
Atención, os teus ficheiros están cifrados.
O contrasinal é exclusivo do teu PC.
Pague a cantidade de 0.05 BTC ao enderezo de Bitcoin: 1ERtRjWAKyG2Edm9nKLLCzd8p1CjjdTiF
Despois do pago, envíame un correo electrónico, adxuntando o ficheiro pass.key a [protexido por correo electrónico] con notificación de pago.
Despois da confirmación, enviareiche un descifrador para os ficheiros.
Un lobo pretencioso, pensado para mostrarlle á vítima a gravidade da situación. Non obstante, puido ser peor.
Arroz. 1. -Como extra, vouche dicir como protexer o teu ordenador no futuro. -Parece lexítimo.
II. Imos comezar
En primeiro lugar, observamos a estrutura da mostra enviada. Curiosamente, non parecía un ficheiro que fora danado polo ransomware. Abre o editor hexadecimal e bótalle un ollo. Os primeiros 4 bytes conteñen o tamaño do ficheiro orixinal, os seguintes 60 bytes están cheos de ceros. Pero o máis interesante é ao final:
Arroz. 2 Analiza o ficheiro danado. Que chama a atención inmediatamente?
Todo resultou ser moi sinxelo: 0x40 bytes da cabeceira movéronse ata o final do ficheiro. Para restaurar os datos, só tes que devolvelos ao principio. Restableceuse o acceso ao ficheiro, pero o nome segue encriptado e as cousas complícanse con el.
Arroz. 3. O nome cifrado en Base64 parece un conxunto divagado de caracteres.
Imos tentar descifralo clave de paso, enviado polo usuario. Nela vemos unha secuencia de 162 bytes de caracteres ASCII.
Arroz. 4. Quedan 162 caracteres no PC da vítima.
Se observas con atención, notarás que os símbolos repítense cunha determinada frecuencia. Isto pode indicar o uso de XOR, que se caracteriza por repeticións, cuxa frecuencia depende da lonxitude da tecla. Unha vez dividida a cadea en 6 caracteres e XOR con algunhas variantes de secuencias XOR, non conseguimos ningún resultado significativo.
Arroz. 5. Ve as constantes que se repiten no medio?
Decidimos buscar constantes en Google, porque si, iso tamén é posible! E todos eles finalmente levaron a un algoritmo: cifrado por lotes. Despois de estudar o guión, quedou claro que a nosa liña non é máis que o resultado do seu traballo. Cómpre mencionar que este non é un cifrador en absoluto, senón só un codificador que substitúe caracteres por secuencias de 6 bytes. Non hai chaves nin outros segredos para ti :)
Arroz. 6. Unha peza do algoritmo orixinal de autoría descoñecida.
O algoritmo non funcionaría como debería se non fose por un detalle:
Arroz. 7. Morfeo aprobado.
Usando a substitución inversa transformamos a cadea de clave de paso nun texto de 27 caracteres. O texto humano (probablemente) "asmodat" merece especial atención.
Fig.8. USGFDG=7.
Google axudaranos de novo. Despois dunha pequena procura, atopamos un proxecto interesante en GitHub - Folder Locker, escrito en .Net e usando a biblioteca 'asmodat' doutra conta de Git.
Arroz. 9. Interface do Locker de cartafoles. Asegúrate de comprobar se hai malware.
A utilidade é un cifrador para Windows 7 e superior, que se distribúe como código aberto. Durante o cifrado, utilízase un contrasinal, que é necesario para o descifrado posterior. Permítelle traballar tanto con ficheiros individuais como con directorios completos.
A súa biblioteca usa o algoritmo de cifrado simétrico Rijndael en modo CBC. Cabe destacar que o tamaño do bloque foi elixido para ser de 256 bits, en contraste co adoptado no estándar AES. Neste último, o tamaño está limitado a 128 bits.
A nosa clave xérase segundo o estándar PBKDF2. Neste caso, o contrasinal é SHA-256 da cadea introducida na utilidade. Só queda atopar esta cadea para xerar a clave de descifrado.
Ben, volvamos ao noso xa descodificado clave de paso. Lembras esa liña cun conxunto de números e o texto "asmodat"? Tentemos usar os primeiros 20 bytes da cadea como contrasinal para Folder Locker.
Mira, funciona! A palabra en clave xurdiu, e todo foi descifrado perfectamente. A xulgar polos caracteres do contrasinal, é unha representación HEX dunha palabra específica en ASCII. Tentemos mostrar a palabra de código en forma de texto. Obtemos 'lobo sombra'. Xa estás a sentir os síntomas da licantropía?
Vexamos outra vez a estrutura do ficheiro afectado, agora sabendo como funciona o armario:
02 00 00 00 – modo de cifrado de nomes;
58 00 00 00 – lonxitude do nome do ficheiro cifrado e base64;
40 00 00 00: tamaño da cabeceira transferida.
O propio nome cifrado e a cabeceira transferida resáltanse en vermello e amarelo, respectivamente.
Arroz. 10. O nome cifrado resáltase en vermello, a cabeceira transferida resáltase en amarelo.
Agora imos comparar os nomes cifrados e descifrados en representación hexadecimal.
Estrutura dos datos descifrados:
78 B9 B8 2E – lixo creado pola utilidade (4 bytes);
0С 00 00 00 – lonxitude do nome descifrado (12 bytes);
A continuación vén o nome do ficheiro real e o recheo con ceros ata a lonxitude de bloque necesaria (recheo).
Arroz. 11. IMG_4114 parece moito mellor.
III. Conclusións e conclusión
De volta ao principio. Non sabemos que motivou o autor de Wulfric.Ransomware e que obxectivo perseguiu. Por suposto, para o usuario medio, o resultado do traballo incluso dun cifrador deste tipo parecerá un gran desastre. Os ficheiros non se abren. Todos os nomes desapareceron. En lugar da imaxe habitual, hai un lobo na pantalla. Obríganche a ler sobre bitcoins.
É certo que esta vez, baixo o pretexto dun "codificador terrible", ocultouse un intento de extorsión tan ridículo e estúpido, onde o atacante usa programas preparados e deixa as chaves xusto na escena do crime.
Por certo, sobre as chaves. Non tiñamos un script ou un troiano malicioso que nos puidese axudar a entender como ocorreu isto. clave de paso – o mecanismo polo que aparece o ficheiro nun PC infectado segue sendo descoñecido. Pero, recordo, na súa nota o autor mencionaba a singularidade do contrasinal. Entón, a palabra en código para descifrar é tan única como o nome de usuario shadow wolf é único :)