Mensajes

mmm... podrías probar Portador316 con un módulo que sepas que funcione bien, en los diferentes slots para descartar que no sea uno de ellos el que te crashee la ram... algó pasó, sobre temperatura, tensión, etc.

Kismet. Saludos.
(obtienes reportes muy interesantes, redes tanto en txt o xml, volcado de paquetes, etc. sino ya deberías irte al volcado desde airodump, luego seguir con el resto de la suite aircrack, pero tomando la info y gestionando las tareas desde un ejecutable por lotes... Tendrías muchas limitaciones, claro.)

No es la misma clave vk496... ni pública, ni la privada. Se generan pares de llaves diferentes para cada host.

Bueno, coincide entonces lo que planteaba de como funcionaba el ransom, el-brujo...
lo malo es que superó mis expectativas de nivel de maldad XD (lo de borrar los puntos anteriores, eso si que es de malévolo... con respecto a la imágenes, bueno pensaba con alguna aplicación de forensis hacer una imagen del disco, y buscar el estado anterior... como se ha cifrado, hay una escritura, por ende se podría buscar los bloques borrados por el indexado anterior. Aunque bueno sería sobre recuperar la información y no encontrarle la vuelta al malware como quería SOFTEL)

Bingo! así es .:UND3R:., y estoy seguro que en los primeros bytes debe figurar la clave... el tema que es la pública XD
(Y por ello no lo descifras luego con el mismo ransom, te envían el decrypter y la respectiva clave (que sirve solo para esa pública, no puedes usarla con otra para recuperar info de otra infección)

(off: aclaro que soy un niño al lado de ustedes .:UND3R:. seguramente esté terriblemente equivocado. Pero si el malware es realmente bueno, debería funcionar así supongo... jajajaaa este finde me pongo con ello, estoy en la oficina tapado de trabajo, se me enfrió el mate, pero el tema es muy interesante! XD)

La clave que necesitas para descifrar algo es siempre la privada (la pública, es la que compartes para que te envíen la información cifrada) La misma está en la base de datos del server... Por eso subes el archivo...

En sí lo que hace el ransom al inicio es establecer alguna clave en el registro (y alguna ubicacion asociada en el disco, supongo que aleatoriamente) para establecer la conexion al servidor... pasar los datos de tu host, seguramente una direccion de bitcoin, etc. etc., o sea, un troyano. Luego, en el server se genera el par de claves, se envía la pública a tu host -se confirman los pasos- y el ransom en el proximo inicio cifra todo lo que sea documentos, fotos etc. Y te envía el mensaje.

Lo que se me ocurre que podrías hacer es en un entorno virtual, verificar este funcionamiento; mirar  el registro del host infectado, mirar con un editor de hexa el ejecutable... ver como trabaja el bichito. y por último armar una pequeña red virtual, uno con el infectado, y con el otro generar un mitm y tratar de sacar algo en limpio con el ssltrip... saludos

Así es dimitrix. Ya sabes, si necesitas de las milésimas, el campo donde guardas el tiempo debe ser de tipo decimal de 17 dígitos (guardas tanto el año como el día y el tiempo en  sí) y defines 3 de ellos para las milésimas. guardas el tiempo en crudo (ejemplo 20150122111915.435) y lo tomas con TIME. (traerá algo como 11:19:15.435)
saludos

no, pero si el decrypter es genuino, debe llevar ya la clave privada en él. Bueno justamente pareciera ser lo que indicas, al descargar junto con el .exe, un archivo plano. No debería haber antes conexión con el servidor por un intercambio. lo haría al inicio para comparar si hay coincidencia entre las públicas alojadas en la bd, y así usar luego la privada, si aún existiera.

(más leyendo el mensaje de inicio que es solo por un tiempo el alojamiento...)

No entiendo que quieres obtener con el ssl, te repito lo que puedes ver es algún paquete de confirmación -en donde luego comenzaría a operar en el siguiente inicio el cifrado- o bien un chequeo para saber si está tu clave pública en su bd.
Igualmente, lo usual es utilizar un proxy intermedio entre los dos host y de esa forma en un sentido la conexión va segura, y en la otra no. Si hay intercambio de credenciales, lo ves en texto plano (no vulneras el protocolo ssl)

Eso puede ser. enviar un paquete de retorno que habilite el descifrado en el cliente. Pero, se presentaría un vulnerabilidad allí... (reinyección del paquete en modo local? debbuguear el ransom y ver que pasa en la pila?) no, a mi corto modo de ver, sería una mala implementación... la llave privada debería estar en el servidor y solo previo pago reenviaría los paquetes descifrados...

(pregunto desde la ignorancia... que garantías hay de haber pagado, y recuperar los archivos? o hay códigos que no se rompen?)

Mmmm... no, lo que debes ver es el cruce de paquetes confirmando la generación exitosa del par de claves... nada más. ( eso es porque por cada infección, generaría un par nuevo, sino si fuera un par genérico, con tal de tener una privada podría publicarse y dejaría de ser efectivo el ransomware... sería como el divulgar una clave simétrica).

Está realmente difícil, más si no hay mucha información al respecto :/

hola SOFTEL, pero con la clave pública no conseguirás nada... la llave pública, la utiliza para cifrar tus archivos... luego la llave privada (alojada en el server, por ejemplo) es la que descifra.   

No creo que nadie sería capaz de poner de acuerdo a todos los países del mundo ni siquiera en declarar que el agua moja

Coincido... siempre habrá un país que tenga "mayor tensión superficial" XD

Lo que sucede es que el "creyente" o si un "pseudo científico", estudia la presencia o no de "fantasmas" entonces si se mueve algo, confirma que fue un fantasma. XD
Mientras, que un científico, o una persoa curiosa del fenómeno (pero con una visión más objetiva...) intentará averiguar si el efecto del objeto movido fue por una causa en particular o bien por la causa x, y, ó z. Saludos