Sexo con crypters

Algunos ya saben que me gusta mantener mis relaciones sexuales con un alto contenido en binario, tras un par de noches de insomnio, me recorria una duda... ¿Cómo funcionaría el Runpe Killer de Psymera? Lo que conozco de dumpear un proceso, requiere que se encuentre ya en memoria, para poder acceder al mismo. Con esta premisa, ¿Podría saltar desde algún sitio hasta mi bicho? Es decir, quien lo quisiera analizar, estaría obligado a infectarse, y si se realiza bien, no se daría cuenta de que ocurrió.

Nota: El destino del tutorial, no es ir infectando, ni haciendo mal. Es demostrar que con una utilidad, "segura", en este caso, una aplicación de defensa, que bien podría ser un antivirus, un firewall, o cualquier otra herramineta. Se tiene tambien que tener siempre cuidado. Por este motivo, es útil, trabajar en máquinas virtuales.

Por lo que aquí, comienza mi aventura analizando algo que no sea un serial.

Probando puntos clave, decido poner un BP (Break Point), en sitios que se me ocurre tendrán que cargar, los bp son:
-GetThreadContext
-CreateProcessA
-SetThreadContext
-WriteProcessMemory
-VirtualAllocEx
-ReadProcessMemory

Si alguien pregunta ¿Por que? Creo que yo, utilizaría esos, para realizar una aplicación de este tipo, sí, SetThreadContext, quizá es un poco abusivo, pero yo el sexo con binarios lo hago duro.

La primera en la frente, bajé un crypter público de indetectables, precisamente algunos de los que nombra el killer, no tenía ganas de codearme uno, y así hacia el reto más complicado, desconocia los vicios programando de ambos bichos.

Primera parada; Puerta de Arganda, lo siento. CreateProcess, me dice que hemos llegado, me llama la atención un punto, el flag del programa está en Deatached_process ¿Por qué? ¿Qué es esto? No me queda muy claro en la especificación de win32 sdk, viene a ser para el correcto funcionamiento de aplicativos de consola. Personalmente creo que no sería necesario pero...

Si me quedo haciendo el bobo, el programa sale directamente en memoria, y tenemos la infección completada, aquí tengo una pista, al salir del ret, descubro que es lo que ocurre... Un SuspendThread, justo antes un push eax, que contiene la dirección del proceso que ha creado recientemente.

De nuevo, si tardo, no sólo lo ejecuta 1 vez, si no que pueden llegar a ser hasta 4 (aumentando en 5 segundos cada vez el tiempo de pausa en sleep). Supongo que busca algo en el proceso creado, al no encontrarlo, lo llama de nuevo. Todo esto, es opinión, aun no lo he analizado.

Traceando veo que realiza una busqueda de EAX = 1, cuando intenta escribir en el proceso, si ha fallado, vuelve a intentarlo una y otra vez, por este motivo se me estaba ejecutando tantas veces; Para solucionarlo con un editor hexadecimal, cambié el EP, por EB FE, un salto sobre si mismo, así dejo el proceso loopeando, y puedo tardar cuanto tiempo quiera, simplente debo recordar restaurar el valor correcto una vez finalizado.

La aplicación realiza:
-Abre la aplicación
-Espera 20 milisegundos ¿? No tengo muy claro, el por que... Supongo que da cuartel para que abra. De ahí que si en 20 milisegundos, no controló la aplicación, la vuelva a llamar (esto es malo, significa INFECTADOS). Personalmente, sin animo de molestar al programador, yo, la hubiese ejecutado directamente pausada. Me evito el trabajo de dormir mi aplicación, y puedo asegurarme que no me infecto. De todos modos, el programador, ya avisa de esta posibilidad.
-Crea una nueva sección donde meterá la ruta del ejecutable, es decir la que utilizará despues, cuando modifica WriteProcessMemory.
-Escribe en la nueva sección creada en el ejecutable,
-GetProcessAddress; Ahora empieza lo divertido
-Localiza: OpenProcess
-Parchea OpenProcess, con 12 bytes, que sólo hacen mover 0 a EAX, para indicar que todo fué bien.
-Localiza: WriteProcessMemory
-Parchea WriteProcessMemory con 127 bytes, guarda los registros, y procede a copiar todo lo que entra en la api, directamente sobre un fichero, cuya ruta está indicada en la sección nueva que crea el programa.
-Finalmente al pulsar el botón, unpack, nos reanuda el proceso, con todas las modificaciones que se han realizado anteriormente.

Mi reto ahora consiste en A) Parchear de forma que el programa realize la carga en suspendido, y no como lo hace actualmente, (por seguridad), B) añadir un código, haré un modulo que exportaré para que lo use quien quiera, que nos permita saltar el actual Runpe Killer; tambien el parcheado por mi.

Pero tanto para obtener el programa como para obtener el modulo tendreis que esperar al próximo post, que con una poca suerte, no será dentro de 3 o 4 meses.

Pd: Por último y no menos importante, agradecer el trabajo a psymera, espero que no se ofenda por algún comentario que hago, de verdad, no son con maldad, lo que has programado está genial. Simplemente aporto una visión diferente.

Un saludo,
WiNSoCk.

¿Por que mi wifi es tuya?

Hoy, por fín, después de mucho tiempo, tuve un rato para "jugar", siempre que esto pasa, ya se sabe, que algo malo ocurre. Esta vez, me encontré que en mi wifi, jugábamos más de los permitidos. Y eso me dio que pensar, ¿Cómo podria saber quien está pasando un buen rato, si lo único que conozco es que se llama “Raul-PC”, y este no es precisamente ningún amiguito mio (ni tampoco me ayuda a pagar las cuotas).

Solución Previa: ¡Cain!

Para sacar más información, pensé en utilizar mi “servidor”, para capturar con CAIN, todo lo que estaba ocurriendo, bien ¡buena idea! El problema es que él (Raúl), no esta siempre que estoy yo. ¡Mala idea! No puedo pedirle que se conecte cuando yo supervise.

Solución segunda: ¡Wireshark!

Como no podia hacer nada con CAIN, preparé wireshark para capturar todo desviando las conexiones a mi “servidor”, pero… Como no todo es tan bello al dibujarlo, me encontré que el trafico generado era demasiado para estar controlandolo constantemente mucho ruido y pocas nueces.

Solución tercera: ¡¡ Ahora sí ¡!

Desactivando el DHCP de mi router, podría indicar por donde tendrían que pasar todas las conexiones, así, me evitaba tener que estar pendiente de CAIN, para envenar ARP.

Para ello, busqué una utilidad que en Windows XP (sí, cada uno usa de servidor lo que quiere), la aplicación se llama: “Simple DNS plus”, esta me permite configurar a mi antojo la configuración DHCP, y así indicar que la puerta de enlace será el mismo y de paso, ¿Por qué no controlar también las solicitudes DNS?

Para poder permitir que Windows XP actúe como router, es decir, permita que las conexiones pasen por el y reenvíe los datos a la puerta de enlace predeterminada (el router original). Hay que modificar en el registro la clave:

HKEY_LOCAL_MACHINE
\SYSTEM
\CurrentControlSet
\Services
\Tcpip
\Parameters

IPEnableRouter == 1

Hasta aquí tenemos, que nuestro equipo nos gestionará DHCP, DNS, y reenviará a la puerta de enlace predeterminada las comunicaciones (todas y de forma transparente). Tan solo nos queda levantar una sesión de cain, ya no es necesario envenenar nada, por que están pasando las conexiones por nosotros. Si es necesario levantar cain, por dos motivos.

1º Para envenenar certificados, y así, nos lleguen las contraseñas en texto plano.

2º Por que nos facilita el trabajo de buscar entre la paja, soy consciente que registra mucho ruido, y no obstante captura también los datos del servidor, pero simplifica mucho.

Tan solo nos queda la prueba de fuego, realizar todo en real, para ello, estoy usando mi portátil como cliente de la wifi.

Lo primero que he comprobado es que el servidor me entrega una dirección ip, es un poco canteo que la puerta de enlace no es una tipica 192.168.0.1, si no que pasa directamente a la nº 6 (192.168.0.6).

Lo segundo es que en el portátil tengo conectividad.

Y por último, que el sistema que he montado realmente captura las contraseñas y por supuesto que funciona perfectamente y de forma transparente para todo aquel que quiera pagar conmigo las cuotas del ADSL.

PD: A pesar de no encontrarme envenenando ARP, si el botón no está pulsado, no falsea los certificados. Nos capturaría el trafico, pero no podríamos ver nada.

Esta solución funciona perfectamente con FIRESHEEP, captura las sesiones y nos permite reimplantarlas en el navegador.

Pd2: Esto nos recuerda que tenemos que tener mucho cuidado con donde nos conectamos, con los avisos de certificados falsos (sí, usando cain los da). Trataré de efectuar cambios y exponer percepciones, usando SSLTrip en vez de cain y también expondré un articulo sobre como defenderse. Conectarnos a redes potencialmente inseguras sin “riesgo”.