Foro de elhacker.net

Buenos días,

Primeras aclaraciones:
  No vengo a preguntar cómo hacer un troyano, ni a pedir un source code de uno de ellos, ni a preguntar como funciona un troyano ya desarrollado.

Segundas aclaraciones. Conocimientos:
  Avanzados en programación en distintos lenguajes. Utilizaré para este proyecto C++ y ASM.
  Básicos de criptografía (Diferenciación entre distintos tipos de criptografía, como por ejemplo simetrica y asimetrica, y conocimientos básicos del funcionamiento de éstos).
  En seguridad, tanto de redes como de aplicaciones (He realizado varias pruebas de concepto. Considero básicas para éste proyecto: Reversing, DLL Injection, API Hooking, Social Engineering - Phising, MiTM, ...)
  Y seguro que alguna cosa más me dejo que necesite para llevar a cabo este proyecto.

Terceras y últimas aclaraciones:
  El proyecto del que voy a haceros unas preguntas trata del desarrollo de un troyano medianamente avanzado. Incluiría rootkit, sistemas de propagación, sistemas de espionaje y sistemas de control. Algo que si en un futuro se pusiera en marcha y tuviera éxito, se pudiera considerar algo como una botnet.

Una vez hechas éstas tan necesarias aclaraciones, voy al grano;
  Quiero empezar a desarrollar malware por cuenta propia (inicialmente para sistemas windows), y tengo una serie de dudas al respecto:
    1. Localización del malware: ¿Cual es la mejor localización de un malware dentro de un sistema? ¿Sistema de arranque, drivers, archivos temporales, ...? ¿Porque?
    2. Antivirus: ¿Cómo un antivirus identifica un proceso malicioso? ¿Que reglas siguen los antivirus más modernos?
    3. ¿Que "estructura o diseño" consideráis la mejor para este tipo de malware? ¿Porque?

He de decir que me he estado mirando las preguntas más frecuentes y sí que es verdad que algunas responderían a mis dudas, pero los posts o se han eliminado o están incompletos y no me dan la información que necesito.

Muchas gracias por leeros el tostón y espero que alguien pueda responderme :)
Un saludo!

No voy a extenderme demasiado:

programa el malware en ring0, los antivirus modernos hookean las APIS de NtCreateFile (por poner un ejemplo) y 40.000 apis más, cualquier cosa que hagas en ring3 podrá ser detectada, analizada y detenida por el AV. Lenguajes únicos para malware: ASM y C, programa un driver o cualquier cosa que corra por ring0/rootkit.

Saludos.

100% de acuerdo. Al rato de escribir el post me acordé que C++ no es un buen lenguaje para trabajar a bajo nivel (Ultimamente estoy trabajando más en diseño de páginas e-commerce y estaba un poco despistado ;) )

En cuanto a lo de Ring0, algo había leído pero no me atrevía a ponerlo por si era una locura trabajar a nivel de drivers. Según tengo entendido los antivirus no pueden acceder a Ring0, lo que me hace pensar ¿cómo los antivirus finalmente detectan el malware que trabaja a ese nivel? Ya que en algún momento u otro tendré que hacer modificaciones de memoria, y eso creo que si es detectable.

Saludos y gracias :)

C++ sirve para bajo nivel tanto como C :silbar: si "new" y "class" parecen de muy alto nivel, siempre se tendrá malloc y struct XD de resto básicamente todo que puedes hacer en C, lo puedes hacer en C++ al mismo nivel...

Al utilizar malloc estás utilizando C sin darte cuenta, ya que pertenece a la librería estándar de C.

justamente por eso lo digo XD

tan simple como que C++ es C... solo que con añadidos que le dan la abstracción de POO de resto es el mismo nivel XD e incluso si usas new y class, no te alejas tanto de de C como muchos hacen creer... es una implementacion de unas asignaciones de memoria adicionales... de resto y fuera de eso creo que muy pocos pueden nombrar donde C++ pueden decir donde se diferencia de C

Piensa que una clase en C++ es una estructura en C la cual contiene punteros a funciones o a miembros internos. Si te fijas en C++ las clases tienen una Virtual Table (vt) el cual es un array de pointers a functions.

Podría elaborar una respuesta gigantesca, pero mejor indico cuales son los mejores procedimientos a seguir en base a tus cuestiones.


La mejor localización es infectar el arranque del OS para que cargue nuestro Kernel Boot Driver antes de que cargue los drivers del sistema, entre los que se incluyen los del AV. Otras opciones serían modificar un driver legítimo, pero su firma digital cambiaría por lo que "Code Integrity" no podría verificar de manera satisfactoria el módulo, por lo que tendrías que patchear Code Integrity y el módulo que carga Code Integrity en el Boot, es decir, patchear CI, Winload y BootMgr.

Con secure boot habilitado BootMgr es verificado por la UEFI gracias a la clave pública embebida en el code del firmware de UEFI (en mi caso ASRock (placa base manufacturer)). Si arrancas antes del AV ganas, así de facil.


Mediante firmas, módulos y llamadas a APIs utilizadas, heurística, detección en tiempo de ejecucción. Un AntiVirus piensa que apenas hace nada, suelen incluir módulos adicionales para lograr lo que he dicho, en mi caso cuento con un AV, FW y un HIPS, siendo el HIPS el módulo que protege los cambios sobre mi sistema (abrir claves del registro, copia de archivos, hookeo de funcs, apertura de handles, elevación ... cualquier cosa que haga un ejecutable).


Sobre programación en Win$ utiliza la DDK (Driver Development Kit) de Win 8.1, pues podrás desarrollar user-mode y kernel-mode drivers para WinVista, Win7 y Win8/8.1. La DDK utiliza su propia implementación para el desarrollo de drivers basado en diseño y uso de interfaces ya definidas.

Sobre las características a incluir, bueno, esto ya es subjetivo, a mi apenas me gusta hacer ruido. Dependiendo del rootkit, éste hará ruido o no. No todos los rootkits son tan potentes como los pintan ahí fuera, lo que hay es un miedo extremo a este tipo de amenazas. Pero su detección si que es algo más tediosa, pero si la amenaza no es gran cosa sigue siendo trivial su eliminación.

Si tienes dudas con los temas de criptografía simplemente postea en el foro correcto y te ayudaré encantado.

Saludos.

Sobre el ring0...

Se puede instalar un driver en una maquina desde codigo?? Hace falta algun tipo de certificado?

------------------------------------------------------------------------------------------------

Yo estoy haciendo una botnet en masm32.

Los bots estan conectados entre si, osea p2p, para que uno se convierta en nodo tiene que tener el upnp activado. Envio los comandos como archivos de texto firmados con gnupg y el bot se descarga y comparte una version reducida de gnupg, el bot si valida el archivo de texto lo guarda y lo comparte.

He terminado una version del protocolo de comunicacion en PHP para instarlo en un servidor para al menos saber que 1 va a ser un servidor.

Antes de empezar todo esto me puse a pensar los posibles problemas que pudiese tener. Vosotros le veis alguno??

Alguien sabe que "operaciones" matematicas hace gnupg para validar que un archivo firmado corresponde a una key publica ??? Me gustaria implementarlo  en el bot para no tener que depender de otro archivo.

El archivo, llamemosle "mi_version_reducida_de_gnupg", se comparte entre todos los bots por medio de su md5sum.
Tambien lo estoy haciendo polimorfico, al empezar la ejecucion hay una funcion que descifra tanto unos opcodes (90 = NOP) y unos bytes en especifico por si hay que hacer un xor al byte actual con otro byte. Una vez descifrado lo que da son unas direcciones de ese archivo a funciones mas "pequeñas" que descifran una parte del bot.
Esto ultimo, el polimorfismo, lo veo mas complicado ya que segun lo veo yo, esta mas enfocado a las matematicas que a la propia programacion.
Al ritmo que voy en unas semanas tendre que decidir entre:
1º Modificar la sección de codigo para hacerla writeable
2º Que el archivo exe al descifrarse haga openfile, writefile y lo ejecute

Entre la 1º y la 2º con cual os quedais??

Para mi, seria mas facil la 1º pero es posible que para los AV si ven un archivo que puede "modificar" su codigo lo tilden de sospechoso


Algun consejo?
Algun error en mis deducciones??
Algun problema visible??

P.D: Quizas mi post no esta muy bien construido, pero son las 6:30 de la mañana y no he pegado ojo

A partir de Windows Vista se introdujo la Driver Signature Enforcement Policy la cual hace uso de la Kernel Mode Code Signing Policy.

Te dejo una breve explicación: tanto en x86 y x64 si Secure Boot está activo tu driver debe de estar firmado por una CA perteneciente al programa de certificación de Microsoft. Obviamente si Secure Boot está activo lo tendrás díficil para bypassearlo, a no ser que exista una vulnerabilidad que te permita deshabilitarlo vía UEFI (alterando la Platform Key).

Si Secure Boot está desactivado, en x86 podrás cargar drivers unsigned o sin firmar, es decir, no necesitan firma digital ni certificado alguno. En x64 sin Secure Boot el driver puede ir firmado por cualquier entidad certificadora (CA) en la que confíe el módulo CI (Code Integrity). La lista es la siguiente -> https://msdn.microsoft.com/en-us/library/windows/hardware/dn170454%28v=vs.85%29.aspx

Info útil:

Como firmar un driver para testeo en nuestro equipo (paso a paso): https://msdn.microsoft.com/en-us/library/windows/hardware/dn653569%28v=vs.85%29.aspx
Política de firmado de drivers en Windows Vista y superior: https://msdn.microsoft.com/en-us/library/windows/hardware/ff548231%28v=vs.85%29.aspx


Para abstraerte de GNUPG debes de saber como funciona la criptografía asimétrica. Cuando envías un archivo cifrado por RSA, lo que haces es generar una clave simétrica (AES) aleatoria, cifras el mensaje con dicha clave y cifras el mensaje y la clave con la clave pública del destinatario. Además, hasheas el mensaje cifrado y la clave y lo cifras con tu clave privada, de esta forma incluyes tu clave pública en el mensaje para que el destinatario pueda verificar la integridad de los digest o hashes.

El destinatario hará las siguientes operaciones:

- Descifras el contenido con la clave privada una vez llegue el mensaje. Computas el hash del descifrado y descifras con la pública del emisor la firma digital. Si ambos hashes coincides el mensaje viene del emisor y no ha sido modificado, por lo tanto confiamos en la clave simétrica y procedemos a descifrar el mensaje.

OJO, hay varias variantes, pero a mí es la que más me tira.

¿Qué operaciones matemáticas? Usando RSA:

Cifrar: m^e (mod N) o m^d (mod N) para firmas digitales.
Descifrar: m^d (mod N) o m^e (mod N) para firmas digitales.

Lo suyo es que si estas en Win$ utilices el la API de RSA o bien utilices las librerías OpenSSL o NSS. También puedes hacerlo tú mismo a mano, no es tedioso una vez sabes el proceso.

Saludos.

Se cifra con la clave publica y se descifra con la clave privada...

Lo que yo necesito se conoce como firmar, es decir, usar mi clave privada y con la publica autentficar la autoria de ese mensaje..

Se puede "cifrar" con la clave privada y descifrar con la publica??

Se usa la misma aritmetica??

Me gustaria poder entender mejor todo esto:

Estoy leyendo esto: http://foro.elhacker.net/criptografia/rsa_para_no_iniciados-t67109.0.html

si... lo unico que distingue la llave privada de la publica es la que te guardas y la que das a conocer...

aquí hace tiempo (https://foro.elhacker.net/buscador-t427548.0.html) hice una vaga explicación de rsa y un algoritmo básico en python que hace la operación

Esta ya es la ultima pregunta sobre el RSA porque no es el tema del hilo..

Si cifro con mi llave privada y descifro con la llave publica, esto seria firmar y confirmar la autoria de un archivo ???
Si en vez de usar un numero como el objeto de lo que se quiere cifrar/firmar, fuese un mensaje en texto plano, como se deberia de cifrar?? byte por byte de forma independiente?
Ejemplo:
Si el mensaje es "hola" se cifra la "h" y da "a", luego la "o" y da "z"... el mensaje cifrado seria "az.." ??

Procura no utilizar el término cifrar junto a la clave privada, ya que el término real es firmar.

Para firmar primero calculas el digest o hash de un mensaje o  de un bloque de de datos. Después firmas dicho digest (m^d (mod N)) y se lo entregas al destinatario junto al mensaje cifrado por AES o en plano. Entonces el destinatario descifra el hash cifrado con tu pública y calcula el hash para el mensaje que le has entregado. Si ambos hashes coinciden el mensaje no ha sido modificado y ha sido enviado por quien dice ser.

Es decir, se respetan los 3 principios clave de la criptografía de clave pública: Integridad (mensaje no modificado), Confidencialidad (aunque capturen el mensaje no podrán hacer nada) y No repudio (sabemos que proviene del emisor y no de otra persona que lo suplante).

Sobre la longitud del mensaje a cifrar, bueno te lo aclaro:

El esquema de cifrado/descifrado en RSA se basa en los grupos multiplicativos de enteros módulo N. La clave pública es un semiprimo llamado N compuesto por dos primos 'p' y 'q'. Al cifrar o descifrar tu utilizas una base 'm' elevada a la 'e' o 'd' como ya dije antes ('e' y 'd' satisfacen la multiplicativa inversa mod phi(N)).

En este caso la base 'm' es una clase de congruencia, es decir, es un número coprimo con N menor que N que genera un conjunto de congruencias coprimas con N.

Básicamente el mensaje tiene que tener longitud N - 1. Te dejo la referencia oficial, está en Inglés, pero su lectura es obligatoria para saber como se implementa RSA en la práctica. La teoría sobre RSA se aprende bien en .pdfs varios, o mismamente KhanAcademy o YouTube. Aunque realmente es aprender sobre teoría de números (number theory).

https://tools.ietf.org/html/rfc3447

Te dejo una pequeña reflexión sobre el cifrado/firma en RSA:

Imagina dos archivos diferentes entre sí pero con hashes casi idénticos. Imagina también que a la hora de firmar firmasemos el hash como tu dices, byte a byte en vez de lo máximo posible.

Si el Hash de ambos dos es de 160bit y son idénticos en los primeros 128bit (16bytes), la firma del mensaje será idéntica en los primeros 16bytes y el problema se reduce a una fuerza bruta de 32bit (4byte), de esta forma consegurías falsificar la firma. Por eso para firmar se firma el hash entero de 160bit o lo que pese ya que N en bits es igual o superior a 1024bits por ende el módulo es superior en tamaño al mensaje.

Saludos.

Muchas gracias por las múltiples respuestas y los enlaces de información.

Me han quedado dudas acerca el SecureBoot:


Es decir, que si está el Secure Boot activado solo tengo dos opciones: Firmar digitalmente como una CA de Microsoft o deshabilitarlo via UEFI mediante una vulnerabilidad, cierto?

Muchas gracias de nuevo y saludos :)