Facebook Recovery un nuevo Phishing que circula por la red social

En los últimos días una nueva oleada de un nuevo phishing se está llevando a cabo a través de esta red social. En esta ocasión, los piratas informáticos están distribuyendo falsos mensajes entre los usuarios donde afirman ser el servicio técnico de Facebook (Facebook Recovery) e indican que van a proceder a desactivar la cuenta si no se sigue el enlace correspondiente.


Tal como podemos ver en la imagen anterior, los piratas informáticos informan al usuario de que si no toma las medidas necesarias se va a desactivar su cuenta definitivamente y no podrá ser recuperada. Junto a dicho mensaje aparece una dirección URL acortada con el dominio j.mp que, al acceder a ella podremos ver cómo nos aparece una nueva página (sospechosa) donde nos pide nuestra dirección de correo o teléfono junto a la contraseña de Facebook.


Una vez se introducen los datos de acceso en la web anterior estos se envían a un servidor en manos de los piratas informáticos que ya han conseguido acceso a la cuenta, sin embargo, esto no acaba aquí. Al iniciar sesión a través del enlace malicioso de los piratas el usuario llegará a una nueva página donde se le pedirán los datos bancarios (nombre, número de tarjeta, etc.) para poder seguir "verificando" la cuenta.



Están claras las intenciones de los piratas informáticos: hacerse con el control de las cuentas y de los datos bancarios para, posteriormente, venderlos en la Deep Web (o utilizarlos en su propio beneficio). Por el momento el enlace malicioso lleva activo desde el día 27 de abril, aunque el número de clicks desde dicha fecha hasta hoy no ha superado los 150. Es posible que a partir de este momento empiece a llegar a más usuarios e incluso que llegue en más idiomas (actualmente sólo está disponible en inglés) para tener así un mayor número de víctimas potenciales.

Para finalizar queremos indicar que este sitio web malicioso ya ha sido identificado por las principales firmas antivirus como podemos ver en VirusTotal aunque igualmente debemos seguir extremando la precaución si no queremos terminar en manos de piratas informáticos.

Engañando al WAF con XMP

Me encontraba tratando de acceder a un hosting por X motivos, digamos que había "algo" interesante para llevarlo a uno a meterse donde no lo invitan, probablemente mas adelante le dedique un apartado en este blog a ese "algo", pero por ahora se los dejare picando. Una vez que había logrado evadir el formulario de autentificación que me llevaba a la zona del admin lo demás parecía sencillo, subir shell mediante uno de los uploads. Había dos tipos: de imagenes y de ficheros pdf.


Este ultimo no realizaba ningún tipo de control sobre la extención del archivo que se le pasaba, pero al momento de enviar la shell era redirigido hacia una respuesta 406.



Al comienzo creí que el WAF filtraba funciones peligrosas como popen, system, shell_exec, etc, pero a medida que probaba me fui dando cuenta de que no permitía la inclusión de los tags <? ?> directamente. Cada vez que trataba de evadir las restricciones para colar mi código seguía recibiendo el cachetazo en seco del 406, cuando se me ocurrió que podía desactivar ModSec con un .htaccess fue en vano, el 406 seguía ahí. Así que ya en las ultimas a punto de desistir tuve la idea de embeber codigo php en el EOF de una imagen del tipo png, y si!, finalmente había subido exitosamente la shell!, pero al momento de llamarla no se ejecutaba!, ¿por qué?.


Por lógica no tendría que haber problema, se tendrían que visualizar los caracteres ilegibles seguidos de mi webshell, esto ya me estaba frustrando. Supuse que quizá se trataba de algún tag abierto dentro del source de la imagen, así que me puse a relojear el code para encontrarme con una cadena que llamo poderosamente mi atención.




XMP es un estándar ISO creado por adobe para el registro de metadatos en formato XML en archivos pdf e imágenes.

Para cerciorarme de que el WAF realmente no restringía el pasaje de la cadena <?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?> decidí subirla en limpio.


Evidentemente había logrado insertar los tags sin recibir un 406 a cambio!, por supuesto al momento de ejecutar el script aparecía un error de sintaxis debido a que lo que se encontraba entre <? ?> no se trataba de una estructura PHP valida, solo faltaba saber ¿hasta que punto controlaba el WAF la regla de la cabecera XMP?.

Jugando un poco con el string a través de ensayo y error, llegue a la conclusión de que los tags podían incluirse siempre y cuando se respete la siguiente regla.


Entonces para disfrazar esta oportunidad y que mi script pasara desapercibido ante ModSec, se me ocurrió crear una función llamada xpacket que iba a contener la instrucción a ejecutar, en este caso descargar una webshell en el servidor.


De esta manera logre hacer a un lado las restricciones para tener una consola de comandos web limpia dentro del hosting.


Probablemente existan muchas otra maneras de saltarse el firewall web, pero esta me pareció de los mas interesante, además de que surgió de la persistencia con un toque de suerte

Autor: [Q]3rv[0]
Fuente: http://www.securitysignal.org/2015/05/enganando-el-waf-con-xmp.html

Como enviar mensajes anónimos por WhatsApp

¿Alguna vez has querido mandar un WhatsApp anónimo por cualquier motivo? A diferencia de las llamadas de voz, que permiten eliminar la identificación y aparecer como “número oculto” o “número privado”, la mensajería instantánea no permite hacer esto. Ahora bien, existen servicios online que nos permiten utilizar la mensajería instantánea, en este caso WhatsApp, de forma anónima.

Ya sea un mensaje de texto, una nota de voz, una fotografía, un vídeo, una vCard o tu ubicación lo que quieras enviar… con esta herramienta puedes hacerlo. Además, te ofrece la posibilidad de enviar un mensaje de WhatsApp anónimo sin nombre, o bien un mensaje de emergencia en el que puedes hacer aparecer tu nombre. Todos estos mensajes, que como es evidente son gestionados por los servidores de Wassame, que presta el servicio, pueden mostrarse de forma pública, o no.

En la captura que acompaña al artículo podéis ver cómo funciona la herramienta, accesible directamente desde el navegador web. En un primer menú horizontal escogemos si queremos enviar un mensaje de texto, una fotografía, un vídeo, una nota de voz, una ubicación o una tarjeta de contecto vCard. A continuación, si queremos un mensaje completamente anónimo, o bien incluir nuestro nombre.



Por último, como es evidente, queda incluir nuestro archivo adjunto, o bien rellenar el cuadro de texto con el mensaje que queremos enviar. Como sistema de seguridad contra bots, este servicio web incorpora un captcha, el cual será necesario que rellenemos correctamente para poder enviar el mensaje correspondiente. Su funcionamiento es así de simple y, siguiendo estos sencillos pasos, enviaremos el mensaje anónimo que queramos al número que hayamos escogido.

Anteriormente existían otras herramientas similares a esta que, por unos motivos u otros, han sido retiradas o han dejado de funcionar. Por el momento, Wassame es una de las únicas alternativas para enviar mensajes de WhatsApp de forma anónima.

SMBMap: busca datos sensibles en recursos compartidos Windows desde Kali

Tenemos disponible en los repositorios de Kali Linux SMBMap, una herramienta que nos permitirá enumerar recursos compartidos samba a lo largo de un dominio. Y no sólo eso, enumera contenidos y permisos, soporta pass-the-hash, descarga/sube/borra ficheros, busca patrones de nombres de fichero con la opción de autodescargarlos e incluso ejecuta comandos en remoto.

https://bugs.kali.org/view.php?id=2248

Esta herramienta fue diseñada teniendo en mente el pentesting y tiene como objetivo simplificar la búsqueda de datos potencialmente sensibles a través de redes de gran tamaño.


Instalación en dos patas:



Algunos ejemplos de autor:


Salida por defecto:




Ejecución de comandos:




Listado de recursos no recursivo (ls):




Búsqueda de contenido en archivos:




Listado de unidades:
Esta característica fue añadida para complementar la búsqueda de conenido.




Shell "elegante":
Ejecuta el script Powershell en el host SMB de la víctima (cambia la IP por la tuya para la conexión inversa).




Listener netcat del atacante:




Para ampliar la información: 
Github: https://github.com/ShawnDEvans/smbmap

Conseguir acceso a router CISCO mediante fuerza bruta.

Pues husmeando con mi propio servicio me dio por probar que tan bien configurada estaba la cosa del lado del ISP que me proporciona el servicio, y la verdad me sorprendi mucho con la flojera que ciertos administradores de red configuran los accesos, valiendose simplemente de un password realmente debil y nada mas, por lo que me dejaron entrar por Telnet de la forma mas sencilla FUERZA BRUTA!!. Posteriormente lo reporte al departamento y me sorprendi de la amabilidad del tecnico que me tomo el reporte, el mismo dia me di cuenta que lo habian solucionado y como punto positivo me decidi a compartir como hacerlo y posteriormente a como evitarlo, aunque esta vez lo hare de forma virtual ya que el acceso real no existe mas (al menos para mi).

A estas alturas la mayoria de nosotros domina los conceptos basicos, pero por si las moscas aqui vamos a definir algunos conceptos valiendonos de Wikipedia.

¿Que es Telnet?

Telnet (Teletype Network1 ) es el nombre de un protocolo de red que nos permite viajar a otra máquina para manejarla remotamente como si estuviéramos sentados delante de ella.

¿Que es fuerza bruta?

Se denomina ataque de fuerza bruta a la forma de recuperar una clave probando todas las combinaciones posibles hasta encontrar aquella que permite el acceso.

¿Que significa un acceso remoto?

En informática, se considera administración remota a la funcionalidad de algunos programas que permiten realizar ciertos tipos de acciones desde un equipo local y que las mismas se ejecuten en otro equipo remoto.

Definidos los conceptos anteriores creo que nos queda super claro lo que vamos a hacer, asi que manos a la obra.


Primero vamos a dejar claro que estas pruebas fueron hechas totalmente de forma virtualizada con GNS3 y una maquina virtual corriendo Kali Linux, asi que asumiré que saben como configurar todo y me saltare el Setting de las mismas.

Normalmente accedemos a internet a travez de un pequeño router instalado en nuestras casas, pero ese router pequeñito no tiene la capacidad de enrutar nuestros paquetes al gran Internet, asi que mas bien se los manda a un Router mas grande que tienes mas capacidad de routing, y es asi como nuestro Default Gateway tiene otro Default Gateway mayor que es realmente quien nos conecta al mundo (es posible que este segundo se los mande a otro aun mas mayor "Backbone Router"). Asi que nuestra red exibe la siguiente topologia:


En un entorno normal se habilitan los acceso remotos a los routers por necesidad de administrarlos de forma remota, lo que significa que cualquiera con un cliente que gestione las conexiones y sabiendo de antemano el password podría entrar a la configuración de los mismos, y una vez dentro todo es posible. En este caso vamos a realizar el post atacando a un router CISCO que hace de Gateway para nuestro router local, en la ilustración es el que llama ISP_Gateway.

Entorno

Host: Kali Linux, dirección IP asignada por DHCP
Victima: ISP_Gateway (Router CISCO), dirección WAN 192.168.11.2
Herramientas: crunch, CAT (Cisco Auditing Tool) y un poco de tiempo.
Entorno de pruebas: 100% Virtual, por lo cual tanto los diccionarios, como el pass solo funcionan para este caso. (Ya que por cuestiones de tiempo creare un diccionario corto para un password muy debil)

Pues ya sentados y con las cabezas frías lo primero es probar la conectividad a nuestro Default_Gateway y para ello bastaría con hacer ping a la dirección del mismo:

ping 10.0.0.1

Con lo cual obtendríamos algo parecido a esto:


Luego a la interfaz WAN de nuestro Default_Gateway:

ping 192.168.1.1

así conseguiríamos esto:


Cabe aclarar que para la prueba estoy utilizando bloques de direcciones privadas, ya que por error no quisiera apuntar mis pruebas a ningún host real en el espacio publico.

Bien, ahora vamos a confirmar la conectividad con la interfaz WAN del ISP_Gateway haciendo ping a la misma:

ping 192.168.11.2

Y se vería así:


Muy bien realizado esto, ya estamos seguros de que la conectividad esta funcionando al 100% asi que vamos a comprobar que si tiene telnet habilitado:

telnet 192.168.11.2

Y si nos responde con un lindo mensaje de bienvenida como este:


Entonces esta habilitado. (Fijense en texto del warning...)

Comprobado todo entonces vamos, manos a la obra!!


Cuando se trata de hacer fuerza bruta muchas personas prefieren descargar diccionarios muy pesados desde Internet, en mi caso particular me gusta mas generar mis propios diccionarios de acuerdo al perfil del objetivo y también por puras vainas mías, esto
es relativo a cada cual, asi que mi primer paso es generar el diccionario usando Crunch, lo hacemos con el siguiente comando:

crunch 5 5 123456789 -o brake_Cisco.txt

5 5 ----> Significa la longitud del password expresado de menor a mayor.
-o  ----> Es el argumento para especificar que queremos guardar la salida en un archivo .txt
brake_Cisco.txt ----> Es el nombre del archivo, le pueden poner el nombre que mas les guste.

Lo cual nos deja algo como esto:


Una vez ya tenemos todo en su lugar solo nos queda atacar, y para esto usaremos una herramienta incluida en Kali Linux que se llama CAT (Cisco Auditing Tool), algo que hay que tener claro es que es posible usar cualquier otra herramienta para fuerza bruta tales como hydra, medusa, jhonn, etc... En esta ocasión utilice esta ya que ademas permite averiguar cosas como la versión de IOS que corre, así como mas información interesante, también es bueno saber que el comando se escribe en mayúscula para que el sistema pueda diferenciar "CAT" de "cat" ya que este ultimo es una herramienta nativa de sistemas GNU para concatenar y comparar valores.

Así que en la consola escribimos el comando:

CAT -h 192.168.11.2 -a brake_Cisco.txt

-h ----> Especifica la dirección del host al que lanzamos el ataque
-a ----> Indica que tenemos un diccionario con el que queremos hacer fuerza bruta. (si no especificamos un diccionario entonces CAT usara un diccionario por defecto que trae de forma nativa)

Y si el password esta en nuestro diccionario, entonces VOILA!!!!

Y una vez sabemos el password valido solo nos queda entrar:


Pues las medidas que se recomiendan para mitigar un poco los ataques de fuerza bruta son casi siempre los mismos:

<> Limitar el numero de intentos de login, asi como el temporizador para admitir nuevos intentos de login (para esto es necesario activar SSH en las lineas telnet)

<> Crear ACL (Acces List) que eviten la conexión de host no deseados, esto sumamente sencillo de hacer y el beneficio es enorme.

<> Se podría configurar un servidor RADIUS para la autenticacion del acceso.

Y fin!!

Si existen mas medidas de seguridad pueden hacer sugerencias, saludos y abrazos a todos mis hermanos de underc0de y hasta la próxima.

VLSM (Variable Lenght Subnet Mask) ¿Que es y como se come?

Pues en el mundo de las redes informaticas las cosas tienen que llegar desde "A" hasta "B" de la forma mas eficaz posible, y no aplica el postulados de la Geometría Euclidiana que dice:

"La forma mas fácil para llegar desde A hasta B es una linea recta"


Para cumplir esa misión los paquetes necesitan de enrutamiento (Routing), tarea que llevan a cabo los enrutadores (Routers) gracias a los protocolos de enrutamiento (Routing Protocols). La verdad no pretendo complicarles la vida explicando cada proceso en las diferentes capas del modelo OSI ya que la idea del material es abordar VLSM, simplemente se explica por ser necesario mas adelante.


Las direcciones IP estan divididas en privadas y publicas y estas a su vez en  clases de acuerdo al valor de su primer octeto, asi:


Como bien dice el post de Expermicid cito textualmente:

Las direcciones IP están compuestas por 32 bits divididos en 4 octetos de 8 bits cada uno. A su vez, un bit o una secuencia de bits determinan la Clase a la que pertenece esa dirección IP.
Cada clase de una dirección de red determina una máscara por defecto, un rango IP, cantidad de redes y de hosts por red.

Podría decirse que la clase de una dirección de red determina su mascara de subred y por ende las direcciones de los host en la red. En el principio del networking cuando IPv4 estaba en pañales jamas se penso que podrian agotarse las direcciones ip, y los sabios de la epoca crearon los protocolos de enrutamiento (recuerdan esas palabras marrones de mas arriba?) para que basándose en los primeros bits de la dirección IP pudieran definir de forma automática la mascara de red. En ese entonces y a primera todo tiene mucho sentido, pero cuando comenzaron a agotarse las direcciones IPv4 se dieron cuenta que habia un desperdicio enorme de direcciones cuando se asignaban direcciones de red con clases, por ejemplo:

Una dirección 172.16.0.0 en binario se vería así:

1 0 1 0 1 1 0 0 . 0 0 0 1 0 0 0 0 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

Y en el enrutamiento con clase de forma automática se asignarían los primeros 16 bit a la parte de RED y el resto a la parte de HOST, con lo que quedaria asi:

1 0 1 0 1 1 0 0 . 0 0 0 1 0 0 0 0 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

Y aqui los listos levantan la mano y preguntan:

¿Pero y cual es el desperdicio en darle esa direccion a una empresa / entidad / institucion?

Pues vamos a imaginar que la ISP asigna este bloque de direcciones a una empresa mediana con 900 equipos finales (telefonos IP, impresoras de red, servidores, etc...)

Vamos a calcular la cantidad de hosts que puede albergar esa direccion (espero se hayan leido el material de Expercimid):

La cantidad de host es = 2^n - 2, siendo "n" el numero de bits en la dirección que pertenecen a host y en nuestro ejemplo tenemos 16 bits de host, así:

                             2 ^ n - 2
                          = 2 ^ 16 - 2
                          = 65,536 - 2
                          = 65,534 direcciones utilizables versus 900 host
                          = 64,634 desperdiciadas
                                  

Ahora imaginemos que la empresa abre una nueva sucursal y necesita direccionamiento para 150 host, la ISP podria proporcionar un nuevo bloque de direcciones, pero debido al agotamiento muy dificilmente lo haga, asi que el administrador de la red debera hacer uso de su arma secreta para redistribuir de forma mas eficiente el mismo bloque de direcciones proporcionado y eso es la tecnica de SUBNETEO (Subneting) explicada por Expercimid.

Y esto tiene dos consecuencias:

a) Los protocolos de enrutamiento mas recientes (recuerdan) no se llevan muy bien con el direccionamiento con clase.

b)Cuando se hace subneting en direccionamiento con clase todas las subredes resultantes tendrán la misma cantidad de host:

SUBRED 0



Max. Hosts    = 32766  (2^15 - 2)
Desperdicio   = 32766 - 900 = 31,866 direcciones
                     
SUBRED 1



Max. Hosts    = 32766   (2^15 - 2)
Desperdicio   = 32766 - 150 = 32,616 direcciones

Y ahora.... Justo ahora es cuando entra en función VLSM
(Por mas que intente no dar preámbulos al final lo hice) 


Para evitar el desperdicio de direccion IPv4 en el año de 1993  la IETF (Internet Engineering Task Force) introdujo CIDR (Classless Inter-Domain Routing ) que trajo como una de las mejoras principales VLSM (Variable Lenght Subnet Mask) Sub-mascara de red con longitud variable, suena complicado pero no lo es...

VLSM es "Tomar una sub-red y dividirla nuevamente cuantas veces sea necesario de acuerdo a las necesidades de la red"

Vamos a cumplir con las mismas necesidades anteriores y con los mismos recursos pero esta vez usando VLSM:

RED 0


Max. Hosts    = 1022   (2^10 - 2)
Desperdicio   = 1022 - 900 = 122 direcciones

RED 1


Max. Hosts    = 254   (2^8 - 2)
Desperdicio   = 254 - 150 = 104 direcciones

Lo que también significa que tendremos 64 subredes para soportar mayores demandas de la red en cuanto a direccionamiento, pero ¿Como que tenemos 64 subredes mas? Pues pasamos de tener 16 bits para la red a tener 22 en la mayor de las subredes:

22 - 16 = 6 bit de RED

Red = 2^n
        = 2^6
        = 64

Parece sencillo pero no lo es...

Debuggear archivos CPL maliciosos

Antes de comenzar, podéis ver qué son los CPL maliciosos aquí:

https://underc0de.org/foro/tutoriales-y-manuales/archivos-cpl-mecanismo-para-propagar-malware/


De la misma forma que una DLL no puede ejecutarse por sí sola (requiere de un EXE que invoque alguno de los exports de la DLL, por ejemplo, rundll32.exe ruta_DLL, export_a_ejecutar), un CPL también requiere que alguien llame a CPlApplet. Sin embargo, dado que CPlApplet recibe diversos mensajes específicos, la ejecución directa con rundll32.exe no será adecuada en tanto esos mensajes no sean enviados.


La clave está entonces en observar que cada vez que se hace doble clic en un CPL se ejecutará control.exe, quien llamará a rundll32.exe con los parámetros adecuados. Luego, control.exe es un buen punto de partida para empezar nuestra sesión de debugging.



En la imagen anterior vemos cómo empezaremos a debuggear control.exe con la ruta hasta el CPL como argumento (esto puede configurarse desde el menú “File > Set New Arguments…”, recordando que hay que presionar Ctrl+F2 para que se tomen los cambios). Luego, vamos a comprobar los nombres referenciados por control.exe, donde se destaca ShellExecuteEx, dado que es el único import que vemos que podría ejecutar rundll32.exe.



Si buscamos en qué partes del código de control.exe se referencia a ShellExecute, encontraremos que esto sucede en un único punto. Así, colocamos un breakpoint en esa instrucción y continuamos la ejecución hasta obtener lo que vemos en la próxima imagen.

Allí, puede apreciarse que rundll32.exe va a ser llamado con los argumentos: “Shell32.dll,Control_RunDLL <ruta_CPL>”. Esto nos da un indicio de por qué no es correcto ejecutar directamente rundll32.exe con el CPL como argumento: es el código contenido en Control_RunDLL, de la librería Shell32.dll, el que sabe cómo pasar los mensajes a CPlApplet.

Asimismo, es importante notar que, la próxima vez que tengamos que debuggear un CPL, podemos empezar por rundll32.exe con estos argumentos que hemos encontrado, sin necesidad de debuggear control.exe antes.




Una vez que estamos detenidos en rundll32.exe, debemos buscar la llamada a Control_RunDLL. Una forma de hacer esto es buscar las referencias a GetProcAddress hasta encontrar aquella que trata de resolver la ubicación del import que buscamos. Así, colocamos breakpoints en todas las llamadas hasta obtener la dirección de Control_RunDLL en Shell32.dll.



Podemos colocar un breakpoint allí y continuar la ejecución. En este momento nos encontramos dentro del código de Control_RunDLL, con lo cual podemos buscar nuevamente las referencias a GetProcAddress para la resolución de CPlApplet.

Sin embargo, queremos capturar el momento en que el CPL se carga en memoria y se ejecuta el entry point (DllMain), ya que allí podría haber algún que otro truquito anti-VM , o incluso el mismo payload malicioso. Entonces, sería conveniente buscar en qué parte del código se llama a LoadLibrary para nuestro CPL.



Como se observa en la imagen, obtendremos muchos puntos del código de Shell32.dll desde donde se llama a LoadLibraryA o LoadLibraryW. A pesar de esto, si luego de colocar todos los breakpoints continuamos la ejecución, el primer LoadLibrary que se ejecutará es el de nuestro CPL. Para que la ejecución quede detenida en la primera instrucción de DllMain, una de las opciones es configurar Olly para que se detenga al cargar el CPL en memoria:



Ahora bien, si volvemos al punto posterior de la llamada a LoadLibrary, encontraremos la referencia a CPlApplet a unas pocas instrucciones de distancia. Eso sí, una vez que estemos en el código de CPlApplet, tenemos que prestar atención a los mensajes que se pasan como argumentos: sólo nos interesa el mensaje CPL_DBLCLK.



Si bien los pasos seguidos en este análisis son interesantes para comprender la ejecución de los archivos CPL, podemos formular un método más práctico para debuggear este tipo de amenazas. Para ello, podemos apoyarnos en la utilización de algún desensamblador como IDA Pro, con el cual podamos identificar la dirección del entry point y de CPlApplet.

Una vez conocidas estas direcciones, podemos abrir directamente el CPL en Olly (haciéndole creer que es un archivo de tipo EXE, y setear los breakpoints en esas direcciones. Luego, si cerramos esa instancia de Olly y abrimos una nueva para debuggear rundll32.exe, tal como hemos descripto, Olly “recordará” esos breakpoints establecidos en el CPL.


En resumen, para debuggear un CPL en forma rápida:

-Observar la dirección de DllMain y de CPlApplet, por ejemplo con IDA Pro.

-Abrir el CPL con Olly y setear los breakpoints donde nos interese. Cerrar OllyDbg.

-Abrir rundll32.exe con Olly, e ingresar “Shell32.dll,Control_RunDLL <ruta_CPL>” en los argumentos.

-Ejecutar hasta que se alcance el primer breakpoint en el CPL.